Date: Fri, 6 Oct 2006 09:15:32 -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: <200610060915.33247.jhb@freebsd.org> In-Reply-To: <f34ca13c0610052000u3d1b2b64kcda29a5e8fa2a216@mail.gmail.com> References: <f34ca13c0610041946h7dfaa05cyf3296798b215405e@mail.gmail.com> <200610051306.58843.jhb@freebsd.org> <f34ca13c0610052000u3d1b2b64kcda29a5e8fa2a216@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 05 October 2006 23:00, Constantine A. Murenin wrote:
> 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?
It's non-zero, and w/o having the source to the firmware, and verifying
that firmware blob you have was built from that source you don't know,
so you are implicitly trusting Intel to not do nasty things in their
firmware (and LSI, etc.). The "not perfect" part is actually my point.
You won't ever be in a position to personally review all of the
software/firmware running on your machine, that's just life, and at some
point you just have to accept that and hope some of the other folks you
are depending on don't screw up. I can't count the number of times I've
run into BIOSen or hardware that blatantly violates the relevant specs
and have to have workarounds as a result, but I still end up writing the
first cut of code based on the spec and deal with the exceptions as they
pop up.
> 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.
Hmm, the one HAL I am familiar with so far (ath(4)) is not OS specific,
only host processor specific. However, why are you worried about how much
work it is for the hardware manufacturer in HAL vs firmware? That's their
choice to make.
> > 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. ;)
When discussing 'security paranoia' you need to figure out who you trust
and who you don't trust. To me it doesn't make sense to trust
${BIGCORPORATION1} who makes a firmware blob, but not trust
${BIGCORPORATION2} who makes a HAL. Both companies are equally opaque to
the typical end-user and thus both of them should be equally (dis)trusted.
In my personal case, I have a very slight relationship with one person
related to the HAL from ${BIGCORPORATION2} so the opaqueness between the
two is slightly different (a partial known vs complete unknown) for me
personally. To me this serves to point out how tricky such judgement calls
can make when you start distrusting the blobs (HAL or firmware) that come
from some companies but not others. Thus, my actual choice is to trust the
blobs from both companies (thus I would happily use either of iwi(4) or
ath(4), and in fact my laptop at work has iwi(4), so that's what I use).
However, we will probably just have to agree to disagree on HAL vs firwmare,
and it's actually my fault for dragging that up in a thread about firmware
licensing.
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200610060915.33247.jhb>