Re: [Stratos-dev] Xen Rust VirtIO demos work breakdown for Project Stratos

[Stefan Hajnoczi <stefanha@xxxxxxxxx>]

On Tue, Sep 28, 2021 at 7:55 AM Christopher Clark
<christopher.w.clark@xxxxxxxxx> wrote:
>
> On Mon, Sep 27, 2021 at 3:06 AM Alex Bennée via Stratos-dev 
> <stratos-dev@xxxxxxxxxxxxxxxxxxx> wrote:
>>
>>
>> Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx> writes:
>>
>> > [[PGP Signed Part:Undecided]]
>> > On Fri, Sep 24, 2021 at 05:02:46PM +0100, Alex Bennée wrote:
>> > That is a significant regression in terms of security model Xen
>> > provides. It would give the backend domain _a lot more_ control over the
>> > system that it normally has with Xen PV drivers - negating significant
>> > part of security benefits of using driver domains.
>>
>> It's part of the continual trade off between security and speed. For
>> things like block and network backends there is a penalty if data has to
>> be bounce buffered before it ends up in the guest address space.
>
>
> I think we have significant flexibility in being able to modify several 
> layers of the stack here to make this efficient, and it would be beneficial 
> to avoid bounce buffering if possible without sacrificing the ability to 
> enforce isolation. I wonder if there's a viable approach possible with some 
> implementation of a virtual IOMMU (which enforces access control) that would 
> allow a backend to commission I/O on a physical device on behalf of a guest, 
> where the data buffers do not need to be mapped into the backend and so avoid 
> the need for a bounce?

This may not require much modification for Linux guest drivers.
Although the VIRTIO drivers traditionally assumed devices can DMA to
any memory location, there are already constraints in other situations
like Confidential Computing, where swiotlb is used for bounce
buffering.

Stefan