Re: Secure KVM

[Anthony Liguori <anthony@codemonkey.ws>]

On 11/07/2011 05:27 AM, Stefan Hajnoczi wrote:
> On Mon, Nov 7, 2011 at 10:17 AM, Sasha Levin<levinsasha928@gmail.com>  wrote:
>
> This is a really interesting topic - something that we've discussed in
> QEMU as well.
>
> Doing it with seccomp is really hard since that only allows read(2),
> write(2), exit(2), and sigreturn(2).  I think using seccomp means that
> host devices (e.g. actual network and block device I/O) are
> implemented outside the seccomp because it requires other syscalls.
> Then the seccomp process would simply do hardware emulation with IPCs
> for all actual I/O.
>
> Where does the VNC server, the image formats, etc go?  It would be
> nice to confine them too.
>
> 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.

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.

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.

Regards,

Anthony Liguori

>
> Stefan
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html