linux-kernel - eradicating out of tree modules (was: : Linux Security *Module* Framework)

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: <47234F73.3040809@imap.cc>
Date:	Sat, 27 Oct 2007 16:47:15 +0200
From:	Tilman Schmidt <tilman@...p.cc>
To:	Adrian Bunk <bunk@...nel.org>
CC:	Greg KH <greg@...ah.com>, Simon Arlott <simon@...e.lp0.eu>,
	Chris Wright <chrisw@...s-sol.org>,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	Jan Engelhardt <jengelh@...putergmbh.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andreas Gruenbacher <agruen@...e.de>,
	Thomas Fricaccia <thomas_fricacci@...oo.com>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	James Morris <jmorris@...ei.org>,
	Crispin Cowan <crispin@...spincowan.com>,
	Giacomo Catenazzi <cate@...ian.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: eradicating out of tree modules (was: : Linux Security *Module* Framework)

Adrian Bunk schrieb:
> On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote:
>> On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
>>> On Fri, Oct 26, 2007 at 01:09:14AM +0200, Tilman Schmidt wrote:
>>>> [...] Once you admit that there is code which, for very good
>>>> reasons, won't ever be accepted into the mainline kernel tree, what you
>>>> are saying amounts to: "Code that isn't fit to be included in the
>>>> mainline kernel isn't fit to exist at all."
>>> What kind of code is not accepted into the mainline kernel tree for good
>>> reasons?
>> - proprietary code
> 
> It's unclear whether distributing not GPL compatible modules is legal
> at all.

We're neither talking about distribution nor legal aspects, but
about existence. But anyway, you seem to agree with me that there
are very good reasons for not including these in the kernel.

> And they are definitely not "very good reasons" for doing anything in 
> the kernel.

There is a big difference between "not doing anything to help"
and "actively doing something to make life difficult for". The
former is undoubtedly legitimate. It's the latter we're
discussing here.

>> - unmaintained code
> 
> Unmaintained code in the kernel has a realistic chance of being usable 
> for 5 years.
> 
> Unmaintained external code is quite likely to be unusable after
> at most one year.

Then why is "being unmaintained" being toted as an argument
*against* inclusion in the kernel?

>> - code conflicting with existing kernel structure or policy
>> - code in which the concerned subsystem maintainers see no benefit
> 
> Let's fix the problems, not work around them.

That's certainly better, but not always possible. Do you
agree with me that if it isn't, then that's a very good
reason for not including that code in the kernel?

> There is a conflict between getting code included and ensuring some 
> minimum quality of the kernel, but in many cases we could try better.

Correct. Again, you appear to agree with my statement that
for some code there are very good reasons not to include it
in the kernel.

> And when there's a good reason for a kernel policy, then code that
> violates this policy is not a "very good reason" for anything.

>> - code which its author is unable and/or unwilling to convert to
>>   kernel coding standards
>> - code whose author is unable and/or unwilling to defend it on LKML
>> ...
> 
> That's their fault, and definitely not a "very good reason" for making 
> life easier for them.

Putting aside the fruitless question of whose fault it is,
is it a "very good reason" for actively making life more
difficult for them than it is already, eg. by gratuitiously
breaking interfaces they rely on for no other "very good
reason" than to discourage out-of-tree development? In other
words, do you think it benefits the Linux community if you
discourage those programmers you've already scared away from
submitting their code to the kernel from continuing their
work off-tree, too? In summary, do you think the world would
be a better place if all the existing out-of-tree modules
just ceased to exist, without any replacement?

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