From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joanna Rutkowska Subject: Re: A few KVM security questions Date: Mon, 07 Dec 2009 18:45:25 +0100 Message-ID: <4B1D3F35.3080206@invisiblethingslab.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> <4B1D3DAC.80508@codemonkey.ws> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDE383BD10CBD9F386C8478A5" Cc: Avi Kivity , kvm@vger.kernel.org To: Anthony Liguori Return-path: Received: from out1.smtp.messagingengine.com ([66.111.4.25]:59111 "EHLO out1.smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758146AbZLGRp1 (ORCPT ); Mon, 7 Dec 2009 12:45:27 -0500 In-Reply-To: <4B1D3DAC.80508@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDE383BD10CBD9F386C8478A5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anthony Liguori wrote: > Joanna Rutkowska wrote: >> Avi Kivity wrote: >> =20 >>> On 12/07/2009 07:09 PM, Joanna Rutkowska wrote: >>> =20 >>>>> 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. >>>>> >>>>> =20 >>>> 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 t= he >>>> code is in kernel mode, it's still only in an unprivileged domain. >>>> >>>> =20 >>> They're not really unprivileged, one can easily program the dma >>> controller of their assigned pci card to read and write arbitrary hos= t >>> memory. >>> >>> =20 >> >> That's not true if you use VT-d. >> =20 >=20 > 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. >=20 Intel VT-d v1 doesn't support interrupt remapping, so I'm sure you're right here. But DoS attack is a different thing then a system subversion (think malware) attack. Of course which one you fear more would depend on your threat model. > 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 robus= t > against malicious operating systems. There are almost certainly untold= > numbers of exploitable hardware bugs that can be used to do all sorts o= f > terrible things to the physical system. >=20 Perhaps, although so far nobody presented a software-only VT-d escape attack. I think it's reasonable to assume some maniacs would discover a one or two in the coming years. Still, probably order of magnitude less likely than a Linux kernel overflow. > 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. >=20 Agree, there are lots of DoS possibilities. It's just that for me, personally, they are not in the threat model. joanna. --------------enigDE383BD10CBD9F386C8478A5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAksdPzoACgkQORdkotfEW86avgCg3nQATSa4N5fCyMYD1MkkpTeZ 02sAoO5txkfJIcV+jj7ih5Wr+DPBJwZO =Upry -----END PGP SIGNATURE----- --------------enigDE383BD10CBD9F386C8478A5--