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 10:44:38 -0600 Message-ID: <4B1D30F6.7050609@codemonkey.ws> References: <4B1CFD93.7090307@invisiblethingslab.com> <4B1D0057.8030707@redhat.com> <4B1D0383.1080306@invisiblethingslab.com> <4B1D0544.9000603@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Joanna Rutkowska , kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from mail-fx0-f213.google.com ([209.85.220.213]:42785 "EHLO mail-fx0-f213.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935017AbZLGQoh (ORCPT ); Mon, 7 Dec 2009 11:44:37 -0500 Received: by fxm5 with SMTP id 5so5170222fxm.28 for ; Mon, 07 Dec 2009 08:44:42 -0800 (PST) In-Reply-To: <4B1D0544.9000603@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity wrote: > No. Paravirtualization just augments the standard hardware interface, > it doesn't replace it as in Xen. NB, unlike Xen, we can (and do) run qemu as non-root. Things like RHEV-H and oVirt constrain the qemu process with SELinux. 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. Regards, Anthony Liguori