From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:39879) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RYf8Z-00084o-6p for qemu-devel@nongnu.org; Thu, 08 Dec 2011 09:39:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RYf8R-0005kL-7L for qemu-devel@nongnu.org; Thu, 08 Dec 2011 09:39:51 -0500 Received: from e39.co.us.ibm.com ([32.97.110.160]:49522) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RYf8R-0005jz-22 for qemu-devel@nongnu.org; Thu, 08 Dec 2011 09:39:43 -0500 Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 8 Dec 2011 07:39:41 -0700 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pB8EdbkG169062 for ; Thu, 8 Dec 2011 07:39:37 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pB8EdaAl029416 for ; Thu, 8 Dec 2011 07:39:37 -0700 Message-ID: <4EE0CC26.4070103@linux.vnet.ibm.com> Date: Thu, 08 Dec 2011 09:39:34 -0500 From: Corey Bryant MIME-Version: 1.0 References: <4EDFAF91.4070904@linux.vnet.ibm.com> <4EDFB4F0.70406@codemonkey.ws> <4EDFBF56.9030607@linux.vnet.ibm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Device sandboxing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Richa Marwaha , Michael Halcrow , qemu-devel@nongnu.org, Eric Paris , Paul Moore , Ashley D Lai , Avi Kivity , Amit Shah , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Eduardo Terrell Ferrari Otubo , Lee Terrell , George Wilson On 12/08/2011 04:47 AM, Stefan Hajnoczi wrote: > On Wed, Dec 7, 2011 at 7:32 PM, Corey Bryant wrote: >> >> >> On 12/07/2011 01:48 PM, Anthony Liguori wrote: >>> >>> On 12/07/2011 12:25 PM, Corey Bryant wrote: >>>> * The trusted helper thread would run beside the untrusted thread, >>>> enabling the untrusted thread to make syscalls beyond read(), >>>> write(), exit(), and sigreturn(). >>> >>> >>> I assume you mean process, not thread BTW? >>> >> >> I do mean thread. When making calls on behalf of the seccomp'd thread, I >> think there will be syscalls that must be called from the same address >> space. That's where the the trusted helper thread would come into play. > > It's worth pointing out that "isolation within the same process" > schemes work by running the trusted thread in a very special execution > environment. It cannot trust memory and cannot use the stack for > control flow. Everything must be done in registers. > > This can be made to work but it's highly unportable across host > architectures and hard to make changes to the trusted helper because > you have to be so careful. > > Stefan > That's a good point. And maybe we would only need the trusted thread for a minimal number of syscalls that must be made from the same address space, like mmap. I think another approach to safely making a call on behalf of an untrusted thread is to pass the call and parameters to a trusted process which sanitizes the parameters, writes them to memory shared with the trusted thread (read-only from the thread side), and the trusted thread can make the call. -- Regards, Corey