linux-kernel - Re: ipw3945 status

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 30 Jul 2006 10:53:05 -0400
From:	Theodore Tso <tytso@....edu>
To:	Kasper Sandberg <lkml@...anurb.dk>
Cc:	Matthew Garrett <mjg59@...f.ucam.org>, Jan Dittmer <jdi@....org>,
	Pavel Machek <pavel@...e.cz>,
	Jirka Lenost Benc <jbenc@...e.cz>,
	kernel list <linux-kernel@...r.kernel.org>,
	ipw2100-admin@...ux.intel.com
Subject: Re: ipw3945 status

On Sun, Jul 30, 2006 at 03:01:17PM +0200, Kasper Sandberg wrote:
> > 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
signed message (using RSA) with a challenge/response protocol embedded
inside that was necessary to configure said device, which is
calculated in userspace and then passed down into the kernel to be
installed into the device so that it could function.  Do we really
want to consider that to be objectionable?

						- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/