Quoth Michel Salim: > 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 will not include a blob free kernel though, unless upstream does it (i.e. what dwmw2 was trying to help Alexandre Oliva with, despite being insulted for trying to help). Regards, -- Conrad Meyer <konrad@xxxxxxxxxx> -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
