From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: A few KVM security questions Date: Mon, 07 Dec 2009 20:34:11 +0200 Message-ID: <4B1D4AA3.2010909@redhat.com> References: <4B1CFD93.7090307@invisiblethingslab.com> <4B1D0057.8030707@redhat.com> <4B1D0383.1080306@invisiblethingslab.com> <4B1D0544.9000603@redhat.com> <4B1D30F6.7050609@codemonkey.ws> <4B1D36E3.9090206@invisiblethingslab.com> <4B1D379C.9020407@redhat.com> <4B1D3840.1000801@invisiblethingslab.com> <4B1D38EB.7000409@redhat.com> <4B1D3C6F.8040806@invisiblethingslab.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , kvm@vger.kernel.org To: Joanna Rutkowska Return-path: Received: from mx1.redhat.com ([209.132.183.28]:65447 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758226AbZLGSeJ (ORCPT ); Mon, 7 Dec 2009 13:34:09 -0500 In-Reply-To: <4B1D3C6F.8040806@invisiblethingslab.com> Sender: kvm-owner@vger.kernel.org List-ID: On 12/07/2009 07:33 PM, Joanna Rutkowska wrote: > >> AFAIK VT-d is only supported in Xen for fully virtualized guests. Maybe >> it changed while I wasn't watching, though. >> >> > Negative. VT-d can be used to contain PV DomUs as well. We actually > verified it. > > Ah, good for them. >> It can use read() and write() (and shared memory) to communicate, just >> like Xen stub domains. >> >> > Well, but the read() and write() syscalls, on a system like Linux, it's > a gate to *lots* of code. These are very powerful system calls. > But you control all the file descriptors. A minimal system would just consist of a pair of eventfd fds for signalling and shared memory (the Xen equivalent is event channels and grant tables). >> It's a lot of surgery, but it can be done. >> >> > And then you have the code with whom this qemu communicates (e.g. the > network stack). You said we could somehow use IPC to delegate it to some > VM (that would have VT-d assigned NIC). But then this VM would need to > use qemu again (of course this time not for net emulation). Looks > non-trivial. > It doesn't really need to be a VM. Once the seccomp constrained qemu processes the guest actions, the result is a fairly simple event stream. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.