Date: Mon, 9 Jan 2012 23:40:14 +0100 From: Alistair Crooks <agc@...src.org> To: oss-security@...ts.openwall.com Subject: Re: Malicious devices & vulnerabilties On Mon, Jan 09, 2012 at 02:57:37PM +0100, Ludwig Nussel wrote: > Nice. Using fuse for mounting hot plugged devices where performance > isn't a priority anyways is what I dream about sometimes too :-) > I wonder how hard it would be to create some glue code and re-use the > existing kernel fs drivers 1:1. I should have quoted further - this is from rump(3) on NetBSD: rump is part of the realization of a flexible anykernel architecture for NetBSD. An anykernel architecture enables using kernel code in a number of different kernel models. These models include, but are not limited to, the original monolithic kernel, a microkernel server, or an exokernel style application library. rump itself makes it possible to run unmodi- fied kernel components in a regular userspace process. Most of the time "unmodified" means unmodified source code, but some architectures can also execute unmodified kernel module binaries in userspace. Examples of different use models are running file system drivers as userspace servers (see p2k(3)) and being able to write standalone applications which under- stand file system images. Regardless of the kernel model used, a rump kernel is a fullfledged ker- nel with its own virtual namespaces, including a file system hierarchy, CPUs, TCP/UDP ports, device driver attachments and file descriptors. This means that any modification to the system state on the host running the rump kernel will not show up in the rump kernel and vice versa. A rump kernel may also be significantly more lightweight than the host, and might not include for example file system support at all. FUSE has some limitations when it comes to devices - the NetBSD version of FUSE is layered on top of the rump puffs, for example, and there is a separate pud(4) "pass to userspace device" subsystem which deals specifically with devices. There's an interesting article on using multiple IP stacks with rump: http://mail-index.netbsd.org/current-users/2011/01/18/msg015464.html I've been working on a system call "hijacking" library on and off for the past 1.5 weeks. Support is at a stage where TCP/IP works and I do my normal web surfing through a rump tcp/ip server (plus I run a third tcp/ip stack for testing). In contrast to heavyweight virtualization (usermode OS etc.), the only setup required is configuring the TCP/IP stack, no rootfs & full installation & long waits are necessary. Server "reboot" takes about 0.01s, so there's hardly a loss of service for some applications with good restart capability such as web browsing (especially since the browser itself does not die). Oh, and this is completely separate from Xen and usermode virtualisation, but we're getting off topic here... Regards, Alistair
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ