Re: [Xen-devel] [PATCH v14 07/11] x86/mm: add an extra command to HYPERVISOR_mmu_update...

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.12.17 at 15:49, <Paul.Durrant@xxxxxxxxxx> wrote:
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: 13 December 2017 14:36
>>  >>> On 13.12.17 at 13:06, <Paul.Durrant@xxxxxxxxxx> wrote:
>> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> >> Sent: 12 December 2017 14:39
>> >> >>> On 12.12.17 at 14:52, <andrew.cooper3@xxxxxxxxxx> wrote:
>> >> > We are deliberately trying to introducing a mechanism whereby a
>> >> > toolstack/device-mode/other semi-privileged entity can map resources
>> >> > belonging to a guest which are not part of the guests physmap.  This is
>> >> > because we deliberately want to move things like emulator rings out of
>> >> > the guest physmap for attack surface reduction purposes.
>> >>
>> >> Correct. What I was trying to point out with my reply is that the
>> >> bypass here removes a check which previously we've been
>> >> relying on: By finding the page in the guest's physmap, we can
>> >> at least be certain that access to the page from outside of Xen is
>> >> expected. With it removed, the only other check is the
>> >> ownership one; the bypass in get_page_from_l1e() then blindly
>> >> allows writable mappings to pages owned by the guest, even if
>> >> they were shared r/o.
>> >>
>> >> So while the relaxation here is deliberate _for the purposes the
>> >> series intends_, we still need to make sure we don't open a path
>> >> for device models to gain access to memory which they aren't
>> >> supposed to be able to write (or just read).
>> >
>> > So, a suggestion would be to use some form of flag on the page (probably a
>> > PGC_ flag?) to tag it as a mappable resource. We can then white-list grant
>> > frames and ioreq frames with the new flag and then make sure use of
>> > MMU_PT_UPDATE_NO_TRANSLATE checks that the mfn is either in the
>> guest P2M
>> > anyway, or tagged as a mappable resource?
>> 
>> This doesn't look to be race free: What about a page having the
>> new flag removed while the page is still mapped, or in the process
>> of being mapped (but already past the check of the flag)?
>> 
> 
> Maybe that wouldn't work then. I don't really have any further suggestions. 
> The big question seems to be what does page ownership actually mean?

Maybe there was a misunderstanding in the first place: Unless you
found an issue with the current version of the patch, I wasn't
actually asking to add any further checking logic. Instead I was
asking to double check that with the remaining (after XSA-248)
ownership assignments we don't have any pages left which could
have a mapping established, _despite_ the new bypass.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel