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: <20120224162109.1bbf157b@redhat.com>
Date:	Fri, 24 Feb 2012 16:21:09 -0200
From:	Mauro Carvalho Chehab <mchehab@...hat.com>
To:	Jidong Xiao <jidong.xiao@...il.com>
Cc:	david@...g.hm, Cong Wang <xiyou.wangcong@...il.com>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: Can we move device drivers into user-space?

Em Thu, 23 Feb 2012 16:01:56 -0500
Jidong Xiao <jidong.xiao@...il.com> escreveu:

> On Thu, Feb 23, 2012 at 3:48 PM,  <david@...g.hm> wrote:
> > On Thu, 23 Feb 2012, Jidong Xiao wrote:
> >
> >>>
> >>> At least UIO drivers are already in Linux kernel, see drivers/uio/.
> >>>
> >>
> >> Oh, so does it make sense to move existing device drivers into user
> >> space? For example, move most of the stuff located under drivers/usb
> >> into user-space?
> >
> >
> > Why would you want to? What advantage are you looking to gain from all the
> > effort?
> >
> Since device drivers are a significant source of bugs in OS. Moving
> them to user space can reduce the impact of these bugs. Otherwise, why
> UIO, or drivers/uio, is accepted by mainstream Linux kernel.

Moving a buggy driver to userspace won't fix the bug. You're just moving
it from one place to another place. Also, the code will likely require changes
to work on userspace, so, the chances are that you're actually introducing more
bugs.

The impact of the bug won't also reduce, on most cases, as the userspace driver
will very likely require root capabilities.

Also, as driver talks directly with the hardware, an userspace block driver
would have access to the raw disk data. So, even if you find a way for it to
run unprivileged, it can still mangle the data written on the disk, and
even have a malicious code there that adds or allows to add a malware at the
disk partitions.

That's said, there are much more eyes inspecting the kernel sources than on any 
other userspace project. So, the risk of a bad code to be inserted unnoticed at
the Linux kernel is degrees of magnitude lower than on an userspace driver.

So, I can't see any advantage on doing something like that.

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

-- 
Cheers,
Mauro

---

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
--
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/