Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20120109224014.GK8030@nef.pbox.org>
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.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.