Re: Secure KVM

[Avi Kivity <avi@redhat.com>]

On 11/07/2011 07:43 PM, Anthony Liguori wrote:
>> In that respect I think Avi's ideas about using safe programming
>> languages (even if just a NaCl toolchain) are nice because they are
>> more general and apply to all of the codebase.
>
>
> It's a nice idea but the NaCL toolchain doesn't have a nice upstream
> story right now.

True.  It doesn't have to be NaCl though, although that's my favorite. 
The biggest advantage is near native speed with no context switches for
RPC.  This allows virtio and hpet to be sandboxed too.

>
> I think seccomp() mode 1 isn't so bad.  It's difficult to boot strap,
> but once you have a reasonable set of RPCs, it shouldn't be all that
> bad of an environment to program in.

It should be exactly the same as today's qemu.  We port the qemu_* APIs
to our rpc, and everything should just work (but no direct memory access
any more - everything goes through the APIs).

>
> One way to think of a seccomp() sandbox is that it emulates the legacy
> device model and translates everything into an ultra-modern, no
> backwards compat, pure-virtio device model.  From a QEMU perspective,
> it would treat the sandbox as part of the guest, and then implement a
> bare bones machine that only exposed the couple of virtio interfaces
> to the sandbox.  QEMU would then bridge this to the various types of
> backends.

I don't see how it works - some devices reference the guest address
space, which we can't touch.

How would you bridge IDE to virtio?  Create a third address space for
the internal virtio device?

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.