Re: Malicious devices & vulnerabilties

[Alistair Crooks <agc () pkgsrc org>]

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