Potential nonfree code in Linux-libre

Mon Aug 23 20:59:18 UTC 2021

Thanks for investigating further. I also looked at the datasheet, and it
mentions that "The whole system is controlled by an embedded
microprocessor that is running firmware stored in an internal ROM" and
"During initialize mode the device firmware may be patched," which
seems to suggest that this is a firmware patch. However, I cannot find
a copy of the firmware patch anywhere besides the kernel source.

On Mon, 23 Aug 2021 16:29:21 -0300
Felipe Sanches <juca at members.fsf.org> wrote:

> I actually meant "new - old stock" (parts that are preserved as "new"
> but from an untouched stock of old parts). In general these stocks
> are kept only for the purpose of using those parts to repair obsolete
> equipment.
> 
> Em seg., 23 de ago. de 2021 às 16:26, Felipe Sanches
> <juca at members.fsf.org> escreveu:
> 
> > I looked up the datasheet for the vs6624 chip. All of the memory
> > positions with a meaningful #define on vs6624_regs.h are the ones
> > documented on the datasheet. There are a few without #defines but
> > with somewhat meaningful names placed on comments. I suspect that
> > those were either figured out by reverse engineering or else the
> > developer of this driver got access to complementary docs.
> >
> > There is also a large number of undocumented memory positions that
> > are written to the chip (the vs6624_p1 array). I was curious to see
> > if these "look like code" so I wrote a small python script to
> > create a 64kbyte file with the contents resulting from performing
> > all those writes. By inspecting the result on a hex editor, I see
> > that a few mostly contiguous memory regions are filled with those
> > bytes, which could either mean some code-blocks or some
> > special-purpose range of registers. I also observed that these
> > values are all written to a different memory range (mostly at 9xxx)
> > than the documented registers (from 0x0000 to 0x2616). So it might
> > indeed have a different purpose.
> >
> > The datasheet also mentions that this 64k address range contains a
> > mix of RAM, ROM and "real registers". My hunch is that ROM has
> > firmware written on the factory that uses RAM for its stack and
> > run-time variables but also for reading user-provided settings.
> > Those settings would be the ones documented on the datasheet.
> >
> > There's some small chance that the ROM code is written with hooks to
> > optional extensions to be loaded on RAM by the user, but that
> > sounds way too fancy, in my opinion.
> >
> > Since the chip is manufactured by ST MicroElectronics, the embedded
> > MCU must be one of the cores that ST has. So it might be something
> > like SMT8x perhaps. Maybe we could try disassembling that block of
> > bytes with the opcode table of one of these ST cores to see if it
> > makes any sense.
> >
> > Also, I could not find which devices use this camera other than a
> > very old and discontinued phone. And the only parts I could find to
> > buy are on ebay for ~20 dollars and listed as "old-new stock". And
> > these chips are also listed as "obsolete" on some online electronic
> > parts catalogs.
> >
> > So here's my suggestion for the LinuxLibre project, I have a more
> > pragmatic approach.
> > We lack info on this and it could really be anything. I suggest
> > removing it and waiting until someone complains. Probably nobody
> > will ever complain because it is extremely unlikely someone is
> > nowadays running LinuxLibre on a device that uses this chip. And if
> > such person exists, then we may have the chance of actually poking
> > the device to figure out more technical info about it (such as
> > dumping its internal ROM and disassemblying it to figure out what
> > is it actually doing with the values written to all of those
> > undocumented memory positions).
> >
> > Happy Hacking!
> > Felipe "Juca" Sanches
> >
> > Em sex., 20 de ago. de 2021 às 02:15, Alexandre Oliva
> > <lxoliva at fsfla.org> escreveu:
> >  
> >> Hello, Legimet,
> >>
> >> Thanks for the report.
> >>
> >> On Aug 18, 2021, Legimet <legimet.calc at gmail.com> wrote:
> >>  
> >> > I noticed that there are some files which are included in
> >> > Linux-libre, but stripped from Debian's kernel:  
> >>
> >> That's not so surprising.  Debian has different standards.  They
> >> even have a different Free Software definition, that they apply
> >> equally to software, documentation, functional and non-functional
> >> data.
> >>
> >> We follow the original Free Software definition, as it applies to
> >> software and other works for practical use.  We don't mind
> >> non-executable configuration data, which leads to different
> >> decisions. 
> >> > arch/powerpc/platforms/8xx/micropatch.c  
> >>
> >> I found this one suspicious, as I inherited the package from BLAG
> >> maintainers that followed gNewSense's decision from back then.  I
> >> have never challenged or reversed that decision, out of
> >> understanding that gNewSense had looked into and debated where to
> >> draw the line. 
> >> > drivers/media/i2c/vs6624.c  
> >>
> >> This one looks more like configuration data than code to me.  It's
> >> hard to tell why, and such hunches are by no means absolute, but
> >> there are plenty of other arrays that comes across as data rather
> >> than as code, and that we've retained.  deblob-check explicitly
> >> authorizes this one.
> >>
> >> The filename is indeed different nowadays, but the filename
> >> annotations are completely ignored by deblob-check.
> >>
> >>  
> >> > drivers/video/fbdev/nvidia
> >> > drivers/video/fbdev/riva  
> >>  
> >> > The nvidia and riva drivers contain obfuscated source code,
> >> > according to the Debian dfsg patches:  
> >>
> >> Source code provided with insufficient documentation is less
> >> desirable than properly documented source code, but that's not
> >> enough to make it non-Free Software.
> >>
> >> Whether it meets the requirements for corresponding sources under
> >> the GPL would be more relevant if we'd received it as object code
> >> at first, and had requested the corresponding sources.  Getting
> >> obfuscated code could then be challenged as failing to meet the
> >> obligation to provide the source code.
> >>
> >> We got poor, debatable source code, but it's hardly debatable
> >> that, once one of us compiles that and distributes the object
> >> code, that *is* the corresponding source code we had at our
> >> disposal, that we've used to compile into the object form.  We've
> >> never even had access to something that would be superior as
> >> source code, and we don't even know whether it exists.  So there's
> >> no issue of GPL compliance for *us*, or for our downstream.
> >>
> >>
> >> Absent evidence that there is a better version that was
> >> precompiled into what we're using as sources, we keep it.  I'm not
> >> even sure we'd have a case for removal if there was such evidence.
> >>
> >> I compare this situation with that of the decompiled version of the
> >> Brazilian tax software that I've been using to maintain and update
> >> it since 2007.  The binaries I got at first were LGPLed compiled
> >> Java code with debug info, that decompiled into compilable Java
> >> without comments. That's not the corresponding source code for the
> >> binaries I got, but once I adopted that as the sources I was going
> >> to modify to develop it further, and started mofiying it, it
> >> became source code, and, more than that, it became corresponding
> >> source code for the binaries I've built and distributed out of it.
> >>
> >> In this case again Debian uses different criteria.  And that's
> >> fine. They don't have to ship code (or data) they're not
> >> comfortable shipping, and they're free to modify the software to
> >> suit their needs, and to distribute the modified software if they
> >> wish. 
> >> >> These drivers are also largely redundant with nouveau.  The
> >> >> RIVA 128 (NV3) is not supported by nouveau but is about 15
> >> >> years old and probably discontinued 10 years ago.  
> >>
> >> This is not a relevant argument for us.
> >>
> >> If it's Free Software, or if it's not software but data, we keep
> >> it.
> >>
> >> If it's non-Free Software, or if it's software or documentation
> >> that induces to the use of non-Free Software, we drop it.
> >>
> >>
> >> Thanks again,
> >>
> >> --
> >> Alexandre Oliva, happy hacker
> >> https://FSFLA.org/blogs/lxo/ Free Software Activist
> >>        GNU Toolchain Engineer Disinformation flourishes because
> >> many people care deeply about injustice but very few check the
> >> facts.  Ask me about <https://stallmansupport.org>
> >> _______________________________________________ linux-libre
> >> mailing list linux-libre at fsfla.org
> >> http://www.fsfla.org/cgi-bin/mailman/listinfo/linux-libre
> >>  
> >  