[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] Device sandboxing

From: Blue Swirl
Subject: Re: [Qemu-devel] [RFC] Device sandboxing
Date: Sat, 10 Dec 2011 19:39:54 +0000

On Fri, Dec 9, 2011 at 16:17, Paul Brook <address@hidden> wrote:
>> A group of us are starting to work on sandboxing QEMU device emulation
>> code.  We're just getting started investigating various approaches, and
>> want to engage the community to gather input.
>> Following are the design points that we are currently considering:
>> * Decompose QEMU into multiple processes:
>>      * This could be done such that QEMU devices execute in separate
>>        processes based on device type, e.g. all block devices in one
>>        process and all network devices in a second process.  Another
>>        alternative is executing a separate process per device.
> I can't help wondering if nested virtualization would be a better solution.
> i.e. have an outer VM that only implements a trusted subset of devices. Inside
> that run a VM that provides the flakey legacy device emulation you expect to
> be compromised.

I think Anthony has proposed this also, taking virtio devices as the
trusted subset.

Similar effect from security point of view could be made by forcing
the guest to only use the trusted subset of devices, then the outer VM
equals inner VM. Nesting may provide additional layer of defense and
the subset may limit guest OS selection.

I proposed once a setup where the outer VM would use an encrypted
instruction set (maybe also I/O registers should be encrypted). Then
the guest in the inner VM would have trouble guessing how to break
into it (or how to exploit a vulnerability) or it could try to break
directly into the (presumably x86) host which could be more difficult.
It would not be very difficult for hardware designers to add hardware
support for this though, without that performance would be bad (less
than TCG efficiency squared).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]