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:15:44 +0100 Message-ID: <4B1D3840.1000801@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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3F87BDC16191466D8392E7B9" Cc: Anthony Liguori , kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from out1.smtp.messagingengine.com ([66.111.4.25]:48572 "EHLO out1.smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964805AbZLGRPk (ORCPT ); Mon, 7 Dec 2009 12:15:40 -0500 In-Reply-To: <4B1D379C.9020407@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3F87BDC16191466D8392E7B9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 d= o >>> 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 the= >> code is in kernel mode, it's still only in an unprivileged domain. >> >> =20 >=20 > They're not really unprivileged, one can easily program the dma > controller of their assigned pci card to read and write arbitrary host > memory. >=20 That's not true if you use VT-d. >> 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 >=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... joanna. --------------enig3F87BDC16191466D8392E7B9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAksdOEAACgkQORdkotfEW84kpQCgy+RTNbgqk2mBW8sh2IwO0J+d E/MAnRhOQ4DRSp/TUoszGN5LUvHyvEFo =0zZ+ -----END PGP SIGNATURE----- --------------enig3F87BDC16191466D8392E7B9--