Re: Xen Memory Sharing Query

[Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>]

On 18/07/2022 14:40, Marc Bonnici wrote:
> Hi Andrew,
>
> Thank you very much for your detailed reply, that make things 
> a lot clearer. I did have a few follow up questions.
>
>> gnttab v2 is horribly more complicated.  
> With v2, do the high level behaviours change much from 
> what you have outlined here? Do you expect in the long term 
> for v2 to be the preferred implementation or are they more like 
> alternatives?

That's harder to answer.  v2 comes with new features, but some far
sharper corners.

v2 increased the frame size from 32 bits to 64, so you can address a
frame above the 16T boundary.

v2 also introduces sub-page grants.  These are not mappable, but copyable.

On the other hand, v2 also introduces transitive grants, and these are a
security disaster.  They're largely disabled.

Finally, and most importantly, v2 split the status bits out of flags
field as a performance optimisation, but created an API where there is
no race-free way of invalidating a grant.

>> While a gref is mapped, domA is not permitted to edit the 
>> associated entry.  
> So IIUC once the gref is mapped then domA can't make any changes 
> to the entry at all, (or at least they won't be reflected).

Correct.

> So if 
> domA wants to make any modifications (extend the shared memory 
> region, change permissions etc.), then it would just create another
> entry and share the new gref? 

A grant covers a 4k page (until you start using sub-page grants in v2),
so there isn't really any "extend the region".

For permissions, the only interesting bit is the read-only bit, and that
isn't something you want to be changing midway through the use of the grant.

But yes, you could write a new grant out with new permissions and use that.

>> From a grant perspective, Xen doesn't enforce any policy.  domA's grefs
>> can be mapped in the manner permitted by what domA wrote into the grant
>> table.
> So does this mean that if domA grants access to domB for a given frame, 
> and then added a new entry in its grant table with the same frame details 
> but with "domid = domC" instead. This would be allowed? And if so, would this 
> result in a 3-way shared buffer?

Yes and yes.

I suppose it's worth saying that these are from the point of view of the
mechanics of the grant table interface.

In addition, XSM can be used to provide policy based restrictions.  XSM
Silo is "dom0 all powerful, domU's can only communicate with dom0", and
XSM Flask is rather more like SELinux.

> And finally a similar scenario, if a frame was shared from domA to domB, 
> would domB be able to add an entry in its own grant table to share the 
> same frame with domC and end up with the same outcome?

That's more complicated.  Potentially yes, but it depends on the p2m
checks done when mapping a grant, and I have a suspicion it might be
different between x86 and ARM.

But logically speaking, if domA has granted access to domB, then domB is
permitted to whatever it wants with the mapping, including sharing it
further onwards.  This was the idea behind transitive grants, but the
implementation leaves a lot to be desired.

~Andrew