Date: Thu, 5 Oct 2006 23:00:39 -0400 From: "Constantine A. Murenin" <mureninc@gmail.com> To: "John Baldwin" <jhb@freebsd.org> Cc: freebsd-hardware@freebsd.org Subject: Re: ipw(4) and iwi(4): Intel's Pro Wireless firmware licensing problems Message-ID: <f34ca13c0610052000u3d1b2b64kcda29a5e8fa2a216@mail.gmail.com> In-Reply-To: <200610051306.58843.jhb@freebsd.org> References: <f34ca13c0610041946h7dfaa05cyf3296798b215405e@mail.gmail.com> <200610050852.58943.jhb@freebsd.org> <f34ca13c0610050934n35191e52p2b856224fcee9a12@mail.gmail.com> <200610051306.58843.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 05/10/06, John Baldwin <jhb@freebsd.org> wrote: > 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). Yes, world isn't perfect. But what is the probability that Intel Firmware can possibly do something other than a DoS attack on the host machine, as the machine may have ANY possible operating system on ANY platform? When you have a binary HAL, it's specific to the platform, and that makes the probability of some successful compromise much more plausible than with OS-independent firmwares. And let's not concentrate on just security, but also think of reliability and portability -- binary HALs create the necessity for the hardware manufacturer to update the blob for new platforms / operating systems / compilers / etc. Clearly, binary HALs require way much more hassle than do firmwares, which aren't required to be updated with any possible updates of the OS. > 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 you've just discredited yourself from being objective, as it's now just a matter of your own opinion aka bias of whom you trust and whom you don't trust. ;) Cheers, Constantine.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f34ca13c0610052000u3d1b2b64kcda29a5e8fa2a216>