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 13:58:57 -0600 Message-ID: <4B1D5E81.8010909@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> <4B1D3DAC.80508@codemonkey.ws> <20091207181556.GM4679@tyrion.haifa.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Joanna Rutkowska , Avi Kivity , kvm@vger.kernel.org To: Muli Ben-Yehuda Return-path: Received: from qw-out-2122.google.com ([74.125.92.27]:62897 "EHLO qw-out-2122.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934147AbZLGT6x (ORCPT ); Mon, 7 Dec 2009 14:58:53 -0500 Received: by qw-out-2122.google.com with SMTP id 3so961484qwe.37 for ; Mon, 07 Dec 2009 11:59:00 -0800 (PST) In-Reply-To: <20091207181556.GM4679@tyrion.haifa.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: Muli Ben-Yehuda wrote: > On Mon, Dec 07, 2009 at 11:38:52AM -0600, Anthony Liguori wrote: > > >> 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. >> > > Seems to me that detecting an interrupt storm and shutting the > offending domain and device off is fairly easy for MSI and MSI-X > interrupts, and not-interesting for legacy INTx interrupts. I don't > know that any hypervisor actually implements it, though. > > >> 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. >> > > To the device? Undoubtedly. To the host? I'm not so sure. > But in the context of SR-IOV, impacting the device may result in disrupting (and potentially exploiting) other domains. And I'm waiting for the "malicious guest sets server on fire" CVE :-) I'm convinced there will be at least one. >> 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. >> > > But is there any way the device could do this and also evade detection > of evade being taken off-line by the host, after first killing its > controlling VM? > Thing is, the bus is shared by the host too. So if the guest is able to bring all IO devices on the system to a halt, an administrator certainly couldn't connect remotely to take corrective action. I think all of this could potentially be detected and handled but I assume there's years of research here before that's a reality. >> There is no mechanism to arbitrate this today. It's really a >> dramatically different model from a security perspective. >> > > I think we need to differentiate between assigning full (legacy) > devices, and assigning an SRIOV VF. In the latter---more > interesting---case, the host remains in control of the overall device, > so shutting off a mis-behaving VF should be simple. > SR-IOV is worse IMHO because now there are multiple guests that can be impacted by a hardware exploit. Regards, Anthony Liguori