Date: Thu, 5 Oct 2006 13:06:58 -0400 From: John Baldwin <jhb@freebsd.org> To: "Constantine A. Murenin" <mureninc@gmail.com> Cc: freebsd-hardware@freebsd.org Subject: Re: ipw(4) and iwi(4): Intel's Pro Wireless firmware licensing problems Message-ID: <200610051306.58843.jhb@freebsd.org> In-Reply-To: <f34ca13c0610050934n35191e52p2b856224fcee9a12@mail.gmail.com> References: <f34ca13c0610041946h7dfaa05cyf3296798b215405e@mail.gmail.com> <200610050852.58943.jhb@freebsd.org> <f34ca13c0610050934n35191e52p2b856224fcee9a12@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 05 October 2006 12:34, Constantine A. Murenin wrote: > > you might want to ask Theo why he complains about Intel not giving him a > > license for one binary blob (Intel wireless firmware) but complains about > > Atheros providing a binary blob that he can distribute. Seems a bit of a > > contradiction to me. However, you probably won't make any headway with > > that argument because the other side won't be using reason and logic. > > Are you being serious? The distinction is rather clear -- Intel's > firmware is processor and operating system independent and runs on the > wireless microprocessor, whereas Atheros' HAL module is > processor-dependent, and runs on the main CPU in kernel mode with > unlimited priviledges (correct me if I'm wrong). Clear distinction > here, IMHO. You do realize that on a PCI bus each device (like iwi(4), ipw(4), etc.) is a busmaster, so the firmware on the hardware can DMA to anywhere in physical memory? (Well, on some archs you have an IOMMU to deal with that can make that a bit more tricky, but on i386 and amd64 you don't have that to worry about.) Thus, malicious firmware could engage in kernel object modification, etc. If you're worried about reviewing the source for security bugs, then that worry should be applied to firmware as well as HALs. Taking that argument even further, you really want to review the source for firmware the OS never touches as well (such as on RAID controllers, em(4), etc.) since it still has unmitigated access to all of RAM in the machine. That's still a bit safer than firmware loaded by the OS (easier to sneak in rogue firmware that way as it's loaded more often). In fact, brining up ath(4) vs. iwi(4) specifically: I happen to know the person who compiled the ath(4) HAL personally and trust Sam quite a bit. I haven't the foggiest clue who wrote or built or reviewed the iwi(4) firmware. Running iwi(4) (which I do) takes significantly more "blind faith" for me than ath(4). > > I think in practice that the distinction between a HAL and firmware is > > blurry at best. Both are pre-built software to drive hardware and provide > > a simplified interface to software (i.e. OS) for managing the hardware. > > The only difference is which portion of RAM that it lives (some RAM chip > > on the device or in the RAM of the host computer) and that distinction > > really isn't all that noteworthy. If it's some argument about HAL's > > encroaching on space needed by the OS, note that firmware has to be in > > host RAM as well so it can be uploaded. In fact, for iwi(4) and ipw(4) > > the drivers keep it around all the time to handle suspend/resume. The > > implementation detail of HAL vs firmware is really just a reflection of > > design choices made by the hardware vendor in where to draw the line > > between actual hardware vs software to provide their public interface to > > system software. > > I think there is a huge difference here in what area of the RAM of the > host computer these binary blobs live: in the case of firmware, they > live in a non-executable read-only part of RAM, whereas with a binary > HAL module the situation is just the opposite. And this IS the > difference that should concern security-paranoid people. Actually, I think you aren't _as_ paranoid and underestimate the security implications of binary firmware that is by and large untrusted. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200610051306.58843.jhb>