From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Secure KVM Date: Mon, 07 Nov 2011 20:41:17 +0200 Message-ID: <4EB8264D.2050302@redhat.com> References: <1320612020.3299.22.camel@lappy> <4EB7A45D.1030600@redhat.com> <4EB818D1.70802@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Stefan Hajnoczi , Sasha Levin , Andrea Arcangeli , Marcelo Tosatti , Ingo Molnar , Pekka Enberg , Cyrill Gorcunov , Asias He , Rusty Russell , "Michael S. Tsirkin" , kvm To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:45776 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751133Ab1KGSli (ORCPT ); Mon, 7 Nov 2011 13:41:38 -0500 In-Reply-To: <4EB818D1.70802@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On 11/07/2011 07:43 PM, Anthony Liguori wrote: >> In that respect I think Avi's ideas about using safe programming >> languages (even if just a NaCl toolchain) are nice because they are >> more general and apply to all of the codebase. > > > It's a nice idea but the NaCL toolchain doesn't have a nice upstream > story right now. True. It doesn't have to be NaCl though, although that's my favorite. The biggest advantage is near native speed with no context switches for RPC. This allows virtio and hpet to be sandboxed too. > > I think seccomp() mode 1 isn't so bad. It's difficult to boot strap, > but once you have a reasonable set of RPCs, it shouldn't be all that > bad of an environment to program in. It should be exactly the same as today's qemu. We port the qemu_* APIs to our rpc, and everything should just work (but no direct memory access any more - everything goes through the APIs). > > One way to think of a seccomp() sandbox is that it emulates the legacy > device model and translates everything into an ultra-modern, no > backwards compat, pure-virtio device model. From a QEMU perspective, > it would treat the sandbox as part of the guest, and then implement a > bare bones machine that only exposed the couple of virtio interfaces > to the sandbox. QEMU would then bridge this to the various types of > backends. I don't see how it works - some devices reference the guest address space, which we can't touch. How would you bridge IDE to virtio? Create a third address space for the internal virtio device? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.