linux-kernel - Re: incorrect taint of ndiswrapper

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]

Message-Id: <1161901793.9087.110.camel@dv>
Date:	Thu, 26 Oct 2006 18:29:53 -0400
From:	Pavel Roskin <proski@....org>
To:	Adrian Bunk <bunk@...sta.de>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, Andrew Morton <akpm@...l.org>,
	linux-kernel@...r.kernel.org
Subject: Re: incorrect taint of ndiswrapper

On Thu, 2006-10-26 at 23:46 +0200, Adrian Bunk wrote:
> On Thu, Oct 26, 2006 at 03:19:00PM -0400, Pavel Roskin wrote:
> >...
> > 
> > This means that ndiswrapper would be considered as a derived work of
> > Linux.  Since ndiswrapper is under GPL, it would suffer unfairly if the
> > meaning of EXPORT_SYMBOL_GPL is extended to restrict GPLed modules
> > capable of loading proprietary code into the kernel.
> >...
> 
> You could always write a tiny GPL-ed wrapper module with the sole 
> purpose of offering all EXPORT_SYMBOL_GPL'ed functions through 
> EXPORT_SYMBOL'ed wrapper functions.

Yes, but it's irrelevant.  The kernel should not dictate how ndiswrapper
or any other driver should be structured.

I think such module would be quite inelegant.  It would be a useless
layer of indirection created to compensate for a kernel bug.

> You are using a gnu.org address for publically stating that trying to 
> prevent such kinds of wrapping was unfair?

I didn't even consider this trick.  I was talking about a more
reasonable split of the code loader from the bus-specific code.  Neither
did I suggest that it would be unfair to block any wrapping.  I said it
would be hard and technically infeasible.

I'm using the same e-mail address for all free software work.  I don't
represent Free Software Foundation, although I consider it a honor to
have an account with them.

> It's not even clear that any modules containing non-GPL'ed code were 
> legal.

I'm not a lawyer, but I think one cannot classify software as legal or
illegal.  The law governs what people do.  Running such mix may be legal
even if distribution is not.

Anyway, I don't think it's relevant to ndiswrapper.

> EXPORT_SYMBOL_GPL shows a pretty clear intention, and offering 
> functionality provided throug h EXPORT_SYMBOL_GPL'ed symbols to 
> proprietary code sounds very fishy.

Last time I checked, EXPORT_SYMBOL_GPL was an indication that a code
using it will be considered as a work derived from Linux.  This way,
ndiswrapper, which is free software, can be considered a derived work.

NDIS drivers don't know about any Linux API, therefore they cannot use
it directly.  The purpose of ndiswrapper is not to remove limitations
from the Linux API, but to present a completely different API.

Non-free code does not contains any code derived from Linux because it
wasn't even written for Linux.

-- 
Regards,
Pavel Roskin

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