Re: [RFC PATCH 0/4] Inter-guest virtio I/O example with lguest

[Avi Kivity <avi@qumranet.com>]

Anthony Liguori wrote:
>
> You can have the file descriptor be opened O_RDONLY so trust isn't an 
> issue.
>

Reading is just as bad as writing.

>> This implies trusting the other userspace, which is not a good 
>> thing.  Let the kernel copy, we already trust it, and it has more 
>> resources to do the copy.
>>
>
> You're going to end up with the same trust issues no matter what 
> unless you let the kernel look directly at the virtio ring queue.  
> That's the only way to arbitrate what memory gets copied.  

That's what we need, then.

> There may be a generic API here for fast interprocess IO, I don't 
> know.  splice() is a little awkward though for this because you really 
> don't want to sit in a splice() loop.  What you want is for both sides 
> to be kick'ing the kernel and the kernel to raise an event via 
> eventfd() or something.
>
> Absent whatever this kernel API is (which is really just helpful with 
> a DMA engine), I think the current userspace approach is pretty 
> reasonable.  Not just for interguest IO but also for driver domains 
> which I think is a logical extension.

I disagree.  A driver domain is shared between multiple guests, and if 
one of the guests manages to break into qemu then it can see other 
guest's data.

[Driver domains are a horrible idea IMO, but that's another story]

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/