From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: A few KVM security questions Date: Mon, 07 Dec 2009 11:38:52 -0600 Message-ID: <4B1D3DAC.80508@codemonkey.ws> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Avi Kivity , kvm@vger.kernel.org To: Joanna Rutkowska Return-path: Received: from qw-out-2122.google.com ([74.125.92.26]:2174 "EHLO qw-out-2122.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935542AbZLGRit (ORCPT ); Mon, 7 Dec 2009 12:38:49 -0500 Received: by qw-out-2122.google.com with SMTP id 3so934302qwe.37 for ; Mon, 07 Dec 2009 09:38:55 -0800 (PST) In-Reply-To: <4B1D3840.1000801@invisiblethingslab.com> Sender: kvm-owner@vger.kernel.org List-ID: Joanna Rutkowska wrote: > Avi Kivity wrote: > >> On 12/07/2009 07:09 PM, Joanna Rutkowska wrote: >> >>>> Also, you can use qemu to provide the backends to a Xen PV guest (see -M >>>> xenpv). The effect is that you are moving that privileged code from the >>>> kernel (netback/blkback) to userspace (qemu -M xenpv). >>>> >>>> In general, KVM tends to keep code in userspace unless absolutely >>>> necessary. That's a fundamental difference from Xen which tends to do >>>> the opposite. >>>> >>>> >>>> >>> But the difference is that in case of Xen one can *easily* move the >>> backends to small unprivileged VMs. In that case it doesn't matter the >>> code is in kernel mode, it's still only in an unprivileged domain. >>> >>> >>> >> They're not really unprivileged, one can easily program the dma >> controller of their assigned pci card to read and write arbitrary host >> memory. >> >> > > That's not true if you use VT-d. > I'm skeptical that VT-d in its current form provides protection against a malicious guest. The first problem is interrupt delivery. I don't think any hypervisor has really put much thought into mitigating interrupt storms as a DoS. I think there are a number of nasty things that can be done here. Even if you assume that there aren't flaws in VT-d wrt malicious guests, we have generations of hardware that have not been designed to be robust against malicious operating systems. There are almost certainly untold numbers of exploitable hardware bugs that can be used to do all sorts of terrible things to the physical system. VT-d protects against DMA access, but there's still plenty of things a malicious PCI device can do to harm the physical system. I'm sure you could easily program a PCI device to flood the bus which effectively mounts a DoS against other domains. There is no mechanism to arbitrate this today. It's really a dramatically different model from a security perspective. Regards, Anthony Liguori