Re: [Xen-devel] [PATCH v7 01/12] x86/mm: allow a privileged PV domain to map guest mfns

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 27.09.17 at 13:18, <Paul.Durrant@xxxxxxxxxx> wrote:
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: 25 September 2017 14:03
>> >>> On 18.09.17 at 17:31, <paul.durrant@xxxxxxxxxx> wrote:
>> > -        if ( (real_pg_owner == NULL) || (pg_owner == l1e_owner) ||
>> > +        if ( (real_pg_owner == NULL) ||
>> >               xsm_priv_mapping(XSM_TARGET, pg_owner, real_pg_owner) )
>> >          {
>> >              gdprintk(XENLOG_WARNING,
>> 
>> I'm concerned of the effect of the change on the code paths
>> which you're not really interested in: alloc_l1_table(),
>> ptwr_emulated_update(), and shadow_get_page_from_l1e() all
>> explicitly pass both domains identical, and are now suddenly able
>> to do things they weren't supposed to do. A similar concern
>> applies to __do_update_va_mapping() calling mod_l1_table().
>> 
>> I therefore wonder whether the solution to your problem
>> wouldn't rather be MMU_FOREIGN_PT_UPDATE (name subject
>> to improvement suggestions). This at the same time would
>> address my concern regarding the misleading DOMID_SELF
>> passing when really a foreign domain's page is meant.
> 
> Looking at this I wonder whether a cleaner solution would be to introduce a 
> new domid: DOMID_ANY. This meaning of this would be along the same sort of 
> lines as DOMID_XEN or DOMID_IO and would be used in mmu_update to mean 'any 
> page over which the caller has privilege'. Does that sound reasonable?

Not really, no. Even if the caller has privilege over multiple domains,
it should still specify which one it means. Otherwise we may end up
with a page transferring ownership behind its back, and it doing
something to one domain which was meant to be done to another.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel