linux-kernel - Re: Can we move device drivers into user-space?

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: <alpine.DEB.2.02.1202261503320.4108@asgard.lang.hm>
Date:	Sun, 26 Feb 2012 15:08:34 -0800 (PST)
From:	david@...g.hm
To:	Henrik Rydberg <rydberg@...omail.se>
cc:	Bobby Powers <bobbypowers@...il.com>, "Ted Ts'o" <tytso@....edu>,
	Greg KH <gregkh@...uxfoundation.org>,
	Guenter Roeck <guenter.roeck@...csson.com>,
	Jidong Xiao <jidong.xiao@...il.com>,
	Kernel development list <linux-kernel@...r.kernel.org>
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 
again)

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