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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 25 Oct 2007 19:56:47 -0700
From:	Greg KH <greg@...ah.com>
To:	Tilman Schmidt <tilman@...p.cc>
Cc:	Adrian Bunk <bunk@...nel.org>, 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: Re: Linux Security *Module* Framework (Was: LSM conversion to
	static interface)

On Fri, Oct 26, 2007 at 01:09:14AM +0200, Tilman Schmidt wrote:
> Am 25.10.2007 00:31 schrieb Adrian Bunk:
> > Generally, the goal is to get external modules included into the kernel.
> > [...] even though it might sound harsh breaking
> > external modules and thereby making people aware that their code should 
> > get into the kernel is IMHO a positive point.
> 
> This argument seems to start from the assumption that any externally
> maintained kernel code *can* get into the kernel, which doesn't stand
> up to  reality. 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?  What are these reasons?  What specific code are you talking
about?

I'm trying to compile a list of all known external modules and drivers
and work to get them included in the main kernel tree to help prevent
these kinds of things.  If you know of any that are not on the list at:
	http://linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
please feel free to add them, or email me with the needed information
and I will add them to the list.

thanks,

greg k-h
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ