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  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, 26 Feb 2012 15:08:34 -0800 (PST)
To:	Henrik Rydberg <>
cc:	Bobby Powers <>, "Ted Ts'o" <>,
	Greg KH <>,
	Guenter Roeck <>,
	Jidong Xiao <>,
	Kernel development list <>
Subject: Re: Can we move device drivers into user-space?

On Sun, 26 Feb 2012, Henrik Rydberg wrote:

>>> The main issue that set me off has been sufficiently diluted in the
>>> (selective) discussion so as to no longer make sense as a reply: At
>>> some point, in-tree or out-of-tree will no longer be distinguishable,
>> Please explain how you would be unable to distinguish between a driver
>> that lives in the kernel source tree, and one that does not.
> The SUD pointed to in the beginning of the thread is an example of
> this, but I was not thinking of it in quite so literal terms. Rather,
> I was imagining that as the kernel grows and the in-kernel interfaces
> matures, the amount of actual communication between different portions
> of the code diminishes. Code on opposite sides of a stable interface
> is, for all practical purposes, separated. Whether that code lives
> in-tree or out-of tree is then of little consequence.

the point that you seem to be missing is that the interfaces between the 
different areas of the kernel are not stable, they change over time. When 
both sides of the interface are in the kernel, this is not a problem, both 
sides get changed, but if one side was out of the kernel, then you either 
can't make the change, or have a flag day change where both sides need to 
change in lock-step (and downgrading is hard as both sides need to change 

This is completely ignoring the performance and security aspects of 
userspace components vs kernel components.

Ted is explaining the performance aspects well, but let's look at the 
security aspects as well.

It's not just a case of "if something in userspace crashes, it doesn't 
crash the kerenl", it's also a case that "if you have a userspace 
component, then the kernel must sanity check the userspace interface to 
defend against rogue userspace". Doing these checks is not cheap (adding 
to performance overhead), and may not even be possible (how do you know 
if the command being sent to the SCSI bus is safe or not?)

David Lang
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists