Hi, "C. Bergstr?m" p??e v p? 15. 05. 2009 v 19:35 +0300: > Milan Jurik wrote: > > Hi, > > > > "C. Bergstr?m" p??e v P? 15. 05. 2009 v 15:13 +0300: > > > >> James C. McPherson wrote: > >> > >>> On Fri, 15 May 2009 14:47:27 +0300 > >>> "C. Bergstr?m" <codestr0m at osunix.org> wrote: > >>> > >>> > >>> > >>>> I'm auditing the source and found a couple closed binaries.. I say > >>>> closed binaries because of the wording with the corresponding license > >>>> for each. I'm not sure how this could be fixed, but maybe it's best > >>>> these be moved to the closed binaries download in the future. > >>>> > >>>> usr/src/uts/common/io/usb/clients/hwa1480_fw/i1480/i1480-usb-0.0.bin > >>>> usr/src/cmd/ucodeadm/amd-ucode.bin > >>>> > >>>> > >>> What exactly are you objecting to in the licensing? > >>> > >>> > >> This isn't a license objection.. More just that it doesn't seem > >> appropriate to be in the source tree. It's not source and putting it > >> there is misleading imho.. You've pointed out a few more that I haven't > >> found yet.. Knowing all of these would be helpful. > >> > >> Thanks > >> > >> > > > > Will it make you more happy if it will be embedded as huge char array in > > file with c extension? > > > > Clearly, all these are: > > > > a) microcodes for CPUs > > b) firmwares for some devices > > > > All comming from device developers. > > > > And device driver writers have several different possibilities how to > > include them to their drivers. Many of them prefers to have them in > > separate files, to simplify manipulation. > > > > Look at them like on images (e.g. PNG files). What is the benefit to > > separate them from source tree? > > > (I care much less about the source code for foo.gif than some blob which > be causing a security or stability issue) >
I understand your concerns but I do not see benefit for separating it from the source tree. Many drivers will just stop to work without this firmware, or old, crappy, buggy original firmware from ROM on the card will be used. By separating these blobs from source tree you will receive nothing, only complicate building/maintainance of the source tree. > Looking a bit more into what others are doing.. > > OpenBSD may or may not be sane, but it's a project I have a lot of > respect for. To cite one of their developers and possibly answer my own > question.. > > Reyk Floeter explained, "/there is a major difference between binary > blobs and firmware images; the blobs are loaded as code into the OS > kernel, but the firmware runs directly on the device on crappy embedded > micro CPUs./" > I do not see how this statement has something with the problem of binary blobs (which can be firmware microcode or just set of some values) in our source tree. > So there's a distinction being made here for open software and open > hardware. Blobs possibly being a security risk, but firmware not > executing directly on the host cpu and thus falling into a difference > category. > I think both are possible security risk but I do not still see the benefit to separate such files from the source tree. If you are afraid of them, then you can maintain the list of OS parts which depends on them and do not distribute in your distribution. > So then on there's the edge case of microcode updates. Which generally > happen during a bios upgrade, but for convenience can be loaded each > time on boot.. > > usr/src/cmd/ucodeadm/amd-ucode.bin > usr/src/cmd/ucodeadm/intel-ucode.txt > > i1480-usb-0.0.bin is firmware > > Should these be in the source? > usr/src/tools/tokenize/tokenize.exe: data > usr/src/tools/tokenize/forth: ELF 32-bit MSB executable, > SPARC, version 1 (SYSV), dynamically linked (uses shared libs), stripped > usr/src/tools/ctf/dwarf/i386/libdwarf.cpio.bz2 > usr/src/tools/ctf/dwarf/i386/libdwarf.so.1 > usr/src/tools/ctf/dwarf/i386/libdwarf.a > usr/src/tools/ctf/dwarf/sparc/libdwarf.so.1 > > Maybe some interesting references for the future.. > > http://kerneltrap.org/OpenBSD/That_Which_We_Call_Free > http://www.openbsd.org/lyrics.html#39 > http://lkml.indiana.edu/hypermail/linux/kernel/0903.1/00335.html > > I didn't mean to ruffle feathers, but on first glance and read the > license makes it look very ugly and solely like a binary. Is there a > kernel developer policy on this anywhere? > I am not aware of some policy around binary blobs. Again, I do not see benefit in pushing these blobs outside of the source tree, they are not problem there. They can be problem for some distros, of course. Best regards, Milan
