| 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
| ||
|
Date: Sun, 26 Feb 2012 11:34:14 +0800 From: arts zhao <arts.linux@...il.com> To: "Dr. David Alan Gilbert" <linux@...blig.org> Cc: Mauro Carvalho Chehab <mchehab@...hat.com>, Eduard - Gabriel Munteanu <eduard.munteanu@...ux360.ro>, Jidong Xiao <jidong.xiao@...il.com>, david@...g.hm, Cong Wang <xiyou.wangcong@...il.com>, Kernel development list <linux-kernel@...r.kernel.org>, arts.linux@...il.com Subject: Re: Can we move device drivers into user-space? Basically, I agree with your idea that taking most of device drivers away the kernel scope to user space. Then we can easily debug them and maintain them. However, some device drivers or some layer should be also still existing in kernel scope. such as pci/pcie low-lever driver.... To keep the overhead as lower as possible... thanks -wenke 2012/2/26 Dr. David Alan Gilbert <linux@...blig.org>: > * Mauro Carvalho Chehab (mchehab@...hat.com) wrote: >> Em 25-02-2012 13:10, Eduard - Gabriel Munteanu escreveu: >> > On Fri, Feb 24, 2012 at 04:21:09PM -0200, Mauro Carvalho Chehab wrote: >> >> 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. >> > > > <snip> > >> >> 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. >> > >> > Those much more eyes have already missed important bugs in the past. >> >> Yes, nobody is perfect. But the probability that something passes on a 4000+ people >> review is lower than the probability of a bug on a piece of code where just one >> or two people are looking on it. > > That there are 4000+ people reading a driver is a big assumption; for common > drivers I'd agree - one problem though is there are a lot of drivers for obscure > hardware or old/dead hardware/protocols that frankly near to nobody cares about. > > Very few people read those drivers; yet sometimes they get built and distributed > and someone then finds that since no one has looked at them they're full of holes, > and given a malicious USB device for example, you can suddenly create one of these > devices that only 3 people have bothered to read the source to - 5 years ago. > (The Econet security bug recently would be an example of that). > > There is a line which says that things that really aren't used > just shouldn't be built; but then there are things that are only used > by a few people, and then ones only used by a few organisations - and > it gets very difficult to say at what point you say just turn it off. > > Dave > -- > -----Open up your eyes, open up your mind, open up your code ------- > / Dr. David Alan Gilbert | Running GNU/Linux | Happy \ > \ gro.gilbert @ treblig.org | | In Hex / > \ _________________________|_____ http://www.treblig.org |_______/ > -- > 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/ -- 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/
Powered by blists - more mailing lists