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
| ||
|
Message-ID: <20120225150940.GA3719@localhost> Date: Sat, 25 Feb 2012 17:10:59 +0200 From: Eduard - Gabriel Munteanu <eduard.munteanu@...ux360.ro> To: Mauro Carvalho Chehab <mchehab@...hat.com> Cc: Jidong Xiao <jidong.xiao@...il.com>, 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? 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. Hi, It does provide isolation, see below. > The impact of the bug won't also reduce, on most cases, as the userspace driver > will very likely require root capabilities. Not as proposed, that's the point. For IOMMU-enabled systems, you can safely delegate an entire device to a userspace device and minimize privileged code. If I understand correctly, the performance impact is also minimal with respect to driver <-> device interaction. I'm not sure if driver <-> client might be problematic, but you can probably have the device DMA directly from/into client memory given the right mechanisms. This is currently employed by virtualization software to do PCI passthrough. The guest OS can directly control the hardware. Sure, you can't do it without proper hardware support. The question is how we can reuse existing code. > 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 true, but it still makes sense for other drivers, say NIC drivers. Why should corrupting a network driver possibly result in total privilege escalation? > 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. No disrespect here, I'm just saying in many cases (like the one mentioned above) this approach almost eliminates the issue altogether. It's one reason we keep certain userspace out of the kernel. > So, I can't see any advantage on doing something like that. > Another advantage is you can debug and/or profile the driver more easily. Consider a failed takeover attempt that results in a core dump (which also wouldn't result in a complete DoS of the machine). Anyway, I'm not arguing "this is the way it should be done". After all, not all machines are able to handle such a setup. But don't throw the baby out with the water, it's worth considering ways to make things safer. Also, let's not label things like this one as "microkernel" or "academia" and totally reject them; instead consider whether it's practical given recent advancements. Regards, Eduard -- 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