[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.
