On Sun, Sep 7, 2008 at 7:36 PM, Conrad Meyer <konrad@xxxxxxxxxx> wrote: > Quoth Gregory Maxwell: >> On Sun, Sep 7, 2008 at 3:54 PM, Andrew Haley <aph@xxxxxxxxxx> wrote: >> > Gregory Maxwell wrote: >> > >> >> The notion that firmware ought to be free isn't absurd: It doesn't >> >> take much effort to find examples of firmware imposing unreasonable >> >> limits on users, or firmware containing nasty hidden security bugs. >> > >> > Just to get away from the ethics flame^H^H^H^H^Hdiscussion for a >> > moment... >> > >> > This makes me think of a really interesting question: security- >> > critical organizations presumably have to make use of commercially >> > available computers just like the rest of us. Someone somewhere >> > must have thought about the issues of binary firmware blobs for >> > video and network hardware and their potential to leak data, >> > either deliberately or accidentally. One of the many nice things >> > about free software is the fact that it's reasonably easy to inspect >> > it for security analysis; binary blobs weaken that. >> >> There are two broad classes of 'security-critical organizations', real >> ones and pretenders. Most are pretenders, they fail to consider issues >> like this, then when it fails they show that they tried really hard >> and thus it isn't their fault. Real ones consider these issues, and >> demand manufacturers comply with various security standards which >> validate the security of the hardware/firmware. Manufacturers often >> fail to actually do a good job of this, and can get away with it >> because bad security looks just like good security. ... so then when >> it fails the security-critical organization points to the standards >> that were violated, thus demonstrating the breech was not their fault. >> :) :) >> >> I've found two blobs I use on my systems, one of them very obviously >> is a FPGA image, another one is appears to be software for a small >> micro-controller. I'm not so sure that the FSF would consider the >> FPGA image software, but I don't know that they've considered this >> issue in the context of OS-shipped blobs (in fact, I've heard FPGAs != >> software from them in the past), I think the vast majority of the >> blobs distributed in fedora are software for an embedded general >> purpose CPU and not FPGA images (generally FPGAs are enough of an >> additional per-unit cost thet you don't see them in mass market >> devices). (RME hammerfall firmware is the FPGA image, incidentally). >> >> As was pointed out here, a spin could be created easily enough. It >> would make the FSF happy, as well as some number of other people (it >> would make me happy, if for no other reason than I'd get a better >> understanding of which of these blobs I'm actually using). > > The spin's already been created, it's called BLAG. > That's not really a spin, though, that's a derivative distribution? The idea of my original flame^H^H^H^H^Hquestion is to see what minimal changes we can adopt to make GNU happy. If it's too intrusive then of course it's not really worth it. A spin can only contain packages that are taken from Fedora proper, thus at the minimum we'd need a blob-free kernel. Isolating the other firmware packages should be easier. -- Michel Salim http://hircus.jaiku.com/ -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
