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: <20120226174022.GB3531@kroah.com>
Date:	Sun, 26 Feb 2012 09:40:22 -0800
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Jidong Xiao <jidong.xiao@...il.com>
Cc:	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: Can we move device drivers into user-space?

On Sat, Feb 25, 2012 at 06:43:58PM -0500, Jidong Xiao wrote:
> On Sat, Feb 25, 2012 at 3:55 PM, Greg KH <gregkh@...uxfoundation.org> wrote:
> > On Sat, Feb 25, 2012 at 02:23:07PM -0500, Jidong Xiao wrote:
> >> Hi, Greg,
> >>
> >> These two studies support my point. If the first one is too old, then
> >> the second one should be more convincing. To save your time, you can
> >> take a look at their conclusion first.
> >>
> >> An Empirical Study of Operating Systems Errors
> >> http://www.stanford.edu/~engler/metrics-sosp-01.pdf
> >>
> >> Faults in Linux: Ten Years Later
> >> http://pagesperso-systeme.lip6.fr/Suman.Saha/src/asplos11.pdf
> >
> > This second paper proves my point, it's funny that you tried to use it
> > to prove yours, you obviously must not have read the conclusion...
> >
> > Anyway, any paper that goes "look at all of these problems in the code!"
> > and isn't instantly followed by patches fixing ALL of those problems by
> > the authors of the paper, should be ignored as a troll masquerading as a
> > "study".
> >
> My point was "a significant portion of kernel crash incidents are due
> to bugs in drivers". You said no. I did *not* say bugs in device
> drivers are the dominant factor of kernel crashes/faults. So at least
> my point matches with the conclusion of the second paper. You can
> certainly say these academic studies are meaningless because they are
> not telling the whole story, but you can not deny the fact that
> because of the large code base, it is the almost impossible to
> eliminate all the bugs/problems from device drivers. That's why people
> are doing research to mitigate this problem, even though moving device
> drivers to user space may not be a good idea, or it is unrealistic in
> Linux, those researchers as well as their results deserve more
> respect. Everyone in the whole community, including kernel developers
> and researchers, shares the same goal, namely, improving the kernel
> code quality.

I don't see much help from the majority of researchers toward actually
helping change Linux for the better, their goals usually are just
publishing a paper and then moving on.

Yes, some stick around, and some people are working on making the
intersection between researchers and real-life more condusive toward
helping us out, but that is a hard task given that the goals of the two
groups are usually totally different in the end.

I suggest, if you have the time, to try to work with the researchers to
resolve the problems that they find.  They said that they found hundreds
of problems.  Why aren't those problems all now fixed?  What kept them
from getting fixed after they found them?  Was it something that the
community ignored, or did they not even try?  Find out the root cause of
that, and then, for their next paper, they might have something totally
different to report...

good luck,

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/