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:33:35 +0100 Message-ID: <4B1D3C6F.8040806@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> <4B1D38EB.7000409@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7A6A1CE2C0B7485A37EA8B16" Cc: Anthony Liguori , kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from out1.smtp.messagingengine.com ([66.111.4.25]:45833 "EHLO out1.smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935458AbZLGRdj (ORCPT ); Mon, 7 Dec 2009 12:33:39 -0500 In-Reply-To: <4B1D38EB.7000409@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7A6A1CE2C0B7485A37EA8B16 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Avi Kivity wrote: > On 12/07/2009 07:15 PM, Joanna Rutkowska wrote: >>>> >>>> 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 > AFAIK VT-d is only supported in Xen for fully virtualized guests. Mayb= e > it changed while I wasn't watching, though. >=20 Negative. VT-d can be used to contain PV DomUs as well. We actually verified it. >>>> Sandboxing a process in a monolithic OS, like Linux, is generally >>>> considered unfeasible, for anything more complex than a hello world >>>> program. The process<-> kernel interface seem to be just too fat. = See >>>> e.g. the recent Linux kernel overflows by Spender. >>>> >>>> =20 >>> What about seccomp? You can easily simplify qemu to just a bunch of >>> calculations served over a pipe. >>> >>> =20 >> But the qemu must somehow communicate with the external world too, no?= >> You said you provide e.g. net backend via the qemu process... >> =20 >=20 > It can use read() and write() (and shared memory) to communicate, just > like Xen stub domains. >=20 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. > It's a lot of surgery, but it can be done. >=20 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. joanna. --------------enig7A6A1CE2C0B7485A37EA8B16 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAksdPHYACgkQORdkotfEW87DPgCfYMnfErCrOElUDFDmYXj1oUiD cI8AoIdqSuyZU3/Sm17Tf4gpPQpFsMGX =zHaX -----END PGP SIGNATURE----- --------------enig7A6A1CE2C0B7485A37EA8B16--