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

[Corey Bryant <coreyb@linux.vnet.ibm.com>]

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