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:18:35 +0200 Message-ID: <4B1D38EB.7000409@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> <4B1D379C.9020407@redhat.com> <4B1D3840.1000801@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]:1868 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964814AbZLGRSd (ORCPT ); Mon, 7 Dec 2009 12:18:33 -0500 In-Reply-To: <4B1D3840.1000801@invisiblethingslab.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 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. >> >> > That's not true if you use VT-d. > AFAIK VT-d is only supported in Xen for fully virtualized guests. Maybe it changed while I wasn't watching, though. >>> 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. >> >> > But the qemu must somehow communicate with the external world too, no? > You said you provide e.g. net backend via the qemu process... > It can use read() and write() (and shared memory) to communicate, just like Xen stub domains. It's a lot of surgery, but it can be done. -- error compiling committee.c: too many arguments to function