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 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 07:26:10 -0500
From:	Richard Yao <ryao@...stonybrook.edu>
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, Feb 26, 2012 at 5:47 AM, Henrik Rydberg <rydberg@...omail.se> 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.
>
> To try to prevent another flame war, let's make it clear that I am not
> saying that the most powerful in-kernel argument, that code can be
> changed, is unimportant. Maybe code, like so many other things,
> arranges itself in a scale-free critical fashion, which would forever
> warrant a monolithic approach. Maybe it would even make sense to have
> userspace join the same tree as well. There is however a frofoundly
> political aspect here, which cannot be expressed in terms of
> code. Also, in practise, breaking things down into manageable chunks
> is usually a good idea in the end.

I do not see what prevents an in-kernel context switch into a ring 3
context with a different process address space. Is it necessary to
remove the code from the kernel tree before someone can do this?
--
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/