Re: ipw3945 status

Pavel Machek
2006-07-30T23:13:22Z

Hi!

> > > Because it would involve a moderate rewriting of the driver, and we'd
> > > have to carry a delta against Intel's code forever.
> >
> > without knowing this for sure, dont you think that if a largely changed
> > version of the driver appeared in the tree, intel may start developing
> > on that? cause then they wouldnt be the ones that "broke" compliance
> > with FCC(hah) by not doing binaryonly.
>
> It's just as likely that their lawyers would tell them that they would
> have to pretend that the modifications don't exist at all, and not
> release any changes for any driver (like OpenBSD's) that bypassed the
> regulatory daemon. The bigger worry would be if they decided that
> they couldn't risk supporting their current out-of-tree driver, and
> couldn't release Linux drivers for their softmac wireless devices in
> the future.
>
> Personally, I don't see why the requirement of an external daemon is
> really considered that evil. We allow drivers that depend on firmware
> loaders, don't we? I could imagine a device that required a
> digitally

Well, drivers that depend on external, non-redistributable firmware
(aka ipw2200/ipw2100) already are evil, but at least I do not run
untrusted code on my CPU. (And yes, firmware in ipw2200 crashes a
_lot_).

Plus, that regulatory daemon probably contains security hole (or two)
inside, and I can't properly audit it. (Yes, firmware in ipw2200
probably contains security holes, too, but at least those are more
"interesting" to exploit).

And... Intel will not even tell you WTF that daemon does. They claim
it is for FCC, but it seems to be doing more than that. So maybe I'm
not _that_ paranoid.

(Of course, binary-only kernel module would be even uglier).

Ouch and binary-only daemon will conviently prevent me from using that
wireless card in ppc machine.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html