From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: A few KVM security questions Date: Mon, 07 Dec 2009 19:13:00 +0200 Message-ID: <4B1D379C.9020407@redhat.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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , kvm@vger.kernel.org To: Joanna Rutkowska Return-path: Received: from mx1.redhat.com ([209.132.183.28]:12655 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964789AbZLGRM6 (ORCPT ); Mon, 7 Dec 2009 12:12:58 -0500 In-Reply-To: <4B1D36E3.9090206@invisiblethingslab.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 do >> the opposite. >> >> > 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. > > They're not really unprivileged, one can easily program the dma controller of their assigned pci card to read and write arbitrary host memory. > 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. > What about seccomp? You can easily simplify qemu to just a bunch of calculations served over a pipe. -- error compiling committee.c: too many arguments to function