ipw(4) and iwi(4): Intel's Pro Wireless firmware licensing problems

[Constantine A. Murenin]

On 05/10/06, John Baldwin <jhb at 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.