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

Hi,

My acquaintance with Unix started with FreeBSD, which I used
for quite
a while before discovering OpenBSD. I now mostly use
OpenBSD, and I
was wondering of how many FreeBSD users are aware about the
licensing
restrictions of Intel Pro Wireless family of wireless
adapters?

Why are none of the manual pages of FreeBSD say anything
about why
Intel Wireless devices do not work by default?

http://w
ww.freebsd.org/cgi/man.cgi?query=ipw
http://w
ww.freebsd.org/cgi/man.cgi?query=iwi

If you are curious as to why things are the way they are, I
suggest
that you check the problems that are described in the
miscopenbsd.org
mailing list, and contact Intel people and say what you
think about
their user-unfriendly policy in regards to Intel Pro
Wireless
firmwares, which are REQUIRED to be loaded from the OS
before the
device functions, i.e. the OS developers must be allowed to
freely
distribute the firmware in order for the devices to work
out-of-the-box.

For some recent information about Intel being an Open Source
Fraud,
see http://marc.theaimsgroup.com/?l=openb
sd-misc&m=115960734026283&w=2.

Cheers,
Constantine.
_______________________________________________
freebsd-hardwarefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hard
ware
To unsubscribe, send any mail to
"freebsd-hardware-unsubscribefreebsd.org"

On Wednesday 04 October 2006 22:46, Constantine A. Murenin
wrote:
> Hi,
> 
> My acquaintance with Unix started with FreeBSD, which I
used for quite
> a while before discovering OpenBSD. I now mostly use
OpenBSD, and I
> was wondering of how many FreeBSD users are aware about
the licensing
> restrictions of Intel Pro Wireless family of wireless
adapters?
> 
> Why are none of the manual pages of FreeBSD say
anything about why
> Intel Wireless devices do not work by default?
> 
> http://w
ww.freebsd.org/cgi/man.cgi?query=ipw
> http://w
ww.freebsd.org/cgi/man.cgi?query=iwi
> 
> If you are curious as to why things are the way they
are, I suggest
> that you check the problems that are described in the
miscopenbsd.org
> mailing list, and contact Intel people and say what you
think about
> their user-unfriendly policy in regards to Intel Pro
Wireless
> firmwares, which are REQUIRED to be loaded from the OS
before the
> device functions, i.e. the OS developers must be
allowed to freely
> distribute the firmware in order for the devices to
work
> out-of-the-box.
> 
> For some recent information about Intel being an Open
Source Fraud,
> see http://marc.theaimsgroup.com/?l=openb
sd-misc&m=115960734026283&w=2.

Probably because all you have to do is install a port and it
works. 
In FreeBSD installing a port isn't too difficult for users
to do.  However,
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.

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.  For a software guy to claim that firmware
is ok but
HALs mostly just serves to display how ignorant said person
is of how
things work over in hardware land IMHO.

At this point I've said way more than I probably should as I
have actual
work that I need to be getting done. 

-- 
John Baldwin
_______________________________________________
freebsd-hardwarefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hard
ware
To unsubscribe, send any mail to
"freebsd-hardware-unsubscribefreebsd.org"

On 05/10/06, John Baldwin <jhbfreebsd.org> wrote:
> On Wednesday 04 October 2006 22:46, Constantine A.
Murenin wrote:
> > Hi,
> >
> > My acquaintance with Unix started with FreeBSD,
which I used for quite
> > a while before discovering OpenBSD. I now mostly
use OpenBSD, and I
> > was wondering of how many FreeBSD users are aware
about the licensing
> > restrictions of Intel Pro Wireless family of
wireless adapters?
> >
> > Why are none of the manual pages of FreeBSD say
anything about why
> > Intel Wireless devices do not work by default?
> >
> > http://w
ww.freebsd.org/cgi/man.cgi?query=ipw
> > http://w
ww.freebsd.org/cgi/man.cgi?query=iwi
> >
> > If you are curious as to why things are the way
they are, I suggest
> > that you check the problems that are described in
the miscopenbsd.org
> > mailing list, and contact Intel people and say
what you think about
> > their user-unfriendly policy in regards to Intel
Pro Wireless
> > firmwares, which are REQUIRED to be loaded from
the OS before the
> > device functions, i.e. the OS developers must be
allowed to freely
> > distribute the firmware in order for the devices
to work
> > out-of-the-box.
> >
> > For some recent information about Intel being an
Open Source Fraud,
> > see http://marc.theaimsgroup.com/?l=openb
sd-misc&m=115960734026283&w=2.
>
> Probably because all you have to do is install a port
and it works. 

Oh yeah, so I can install a port to the installation media,
so that I
could setup wireless right away and install all ports that
are not
present on the install CD off an ftp or http mirror? 

> In FreeBSD installing a port isn't too difficult for
users to do.  However,

So is in OpenBSD, in fact, they've recently made it even
easier with a
"-u" option, where "pkg_add -u"
automatically updates all packages to
the newest versions, works out of the box, only PKG_PATH
needs to be
set.

> 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.

> 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.

Cheers,
Constantine.
_______________________________________________
freebsd-hardwarefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hard
ware
To unsubscribe, send any mail to
"freebsd-hardware-unsubscribefreebsd.org"

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
_______________________________________________
freebsd-hardwarefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hard
ware
To unsubscribe, send any mail to
"freebsd-hardware-unsubscribefreebsd.org"

On 05/10/06, John Baldwin <jhbfreebsd.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.
_______________________________________________
freebsd-hardwarefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hard
ware
To unsubscribe, send any mail to
"freebsd-hardware-unsubscribefreebsd.org"

On 10/5/06, Constantine A. Murenin <murenincgmail.com> wrote:
>
> > 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. ;)



Am I the only one who doesn't care what the software license
is so long as I
can use the darned thing without having to sell my soul?
Installing from
ports is A-OK by me, so long as it works, and ipw does.

-Jordan
_______________________________________________
freebsd-hardwarefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hard
ware
To unsubscribe, send any mail to
"freebsd-hardware-unsubscribefreebsd.org"

On Thursday 05 October 2006 23:00, Constantine A. Murenin
wrote:
> On 05/10/06, John Baldwin <jhbfreebsd.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
$ who makes a firmware blob, but not trust
$ 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 $ 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
_______________________________________________
freebsd-hardwarefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hard
ware
To unsubscribe, send any mail to
"freebsd-hardware-unsubscribefreebsd.org"

> > [...]
> > For some recent information about Intel being an
Open Source Fraud,
> > see http://marc.theaimsgroup.com/?l=openb
sd-misc&m=115960734026283&w=2.
> 
> Probably because all you have to do is install a port
and it works. 

Not for me, it doesn't :P
Well, the interface does get created, but the 'no carrier'
state persists
no matter what I do.
I blame our big uncle Intel's old habit of playing posing
games for this
sad state of affairs ;) No good documentation -- no
well-working hardware.
Simple as that.

> 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

firmware is (should be) an integral part of the device, and
runs only
on one CPU. Generally, noone cares about any documentation
for it --
as long as it makes the device work. Thus, binary form is
perfectly
acceptable

OTOH, the code which is intended to be executed by the OS
must not be
distributed in only the binary form, because for some
systems it will
be completely useless (even though the device itself is
perfectly
functional)

> John Baldwin

[SorAlx]  ridin' VN1500-B2
_______________________________________________
freebsd-hardwarefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hard
ware
To unsubscribe, send any mail to
"freebsd-hardware-unsubscribefreebsd.org"