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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 13 December 2017 15:25
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; George Dunlap
> <George.Dunlap@xxxxxxxxxx>; Ian Jackson <Ian.Jackson@xxxxxxxxxx>; Wei Liu
> <wei.liu2@xxxxxxxxxx>; Stefano Stabellini <sstabellini@xxxxxxxxxx>; xen-
> devel@xxxxxxxxxxxxxxxxxxxx; Tim (Xen.org) <tim@xxxxxxx>
> Subject: RE: [PATCH v14 07/11] x86/mm: add an extra command to
> HYPERVISOR_mmu_update...
> 
> >>> 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.
> 

Looking through the code, the only one thing that bothers me is the 
page_set_owner() done in shadow_enable() for the page used for HVM guest vcpus 
that have paging disabled. AFAICT that page would become mappable by an 
emulating domain with MMU_PT_UPDATE_NO_TRANSLATE, if it figured out or guessed 
the correct MFN, but I'm not sure whether damage could be done to Xen using 
that.

  Paul

> Jan


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