linux-kernel - Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

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: <1204305492.3501.83.camel@jcmlaptop>
Date:	Fri, 29 Feb 2008 12:18:12 -0500
From:	Jon Masters <jonathan@...masters.org>
To:	Zan Lynx <zlynx@....org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Pavel Roskin <proski@....org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Jon Masters <jcm@...masters.org>,
	Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only
	symbols

On Fri, 2008-02-29 at 09:59 -0700, Zan Lynx wrote:
> On Fri, 2008-02-29 at 08:08 -0800, Linus Torvalds wrote:
> [cut]
> > It loads non-GPL code, it is non-GPL.
> [cut]
> > Exactly. And ndiswrapper loads proprietary modules.
> 
> The Linux kernel itself will load proprietary modules.  It does not as a
> general rule, but it will.

And when that happens, the same taint flag will be set. Your argument is
a non-argument :)

But anyway...

FWIW, I wasn't actually trying to start this debate with the patch I
sent before - I was simply correcting what seemed to be "obviously"
broken logic in module.c for handling ndiswrapper[0]. I was auditing the
taint flags for a backport to another kernel, and noticed this. Having
said that, there would seem to be two directions this can now go in:

*). Back out this patch, go back to previous situation. But then there's
still special case logic for ndiswrapper, and it's not really doing what
people would likely consider the "right" thing with its tainting then. I
again suggest that ndiswrapper would need to be sure to set the taint
flags itself, which would be an alternative to "policing" it.

*). Keep this patch. And potentially add some more for other similar
shim layers - I can think of a certain graphics driver that might
qualify for similar treatment, if one wants to go there. But I might
need to find a tailor specializing in *really* fire retardant pants
before I think of being the one who submits that patch.

I've no idea what "the right thing" is here, but many seem to think it
involves backing out this patch (the most compelling argument given so
far is that it might force ndiswrapper simply to change its name, and
that there's no clear idea if the kernel should be enforcing ideology).
Since we've brought it up, one good thing I would like to see come of
this perhaps is a clearer understanding of what the kernel should and
should not be doing in terms of "license compliance enforcement". We
have had lots of talk, but perhaps a "policy" document is worthwhile.

Jon.

[0] If this is reverted, please do stick in a reference to:
http://lwn.net/Articles/205644/ to avoid repeats.

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