[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] Device sandboxing

From: Corey Bryant
Subject: Re: [Qemu-devel] [RFC] Device sandboxing
Date: Thu, 08 Dec 2011 09:39:34 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9

On 12/08/2011 04:47 AM, Stefan Hajnoczi wrote:
On Wed, Dec 7, 2011 at 7:32 PM, Corey Bryant<address@hidden>  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.


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]