> -----Original Message----- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 13 December 2017 15:25 > To: Paul Durrant <paul.durr...@citrix.com> > Cc: Andrew Cooper <andrew.coop...@citrix.com>; George Dunlap > <george.dun...@citrix.com>; Ian Jackson <ian.jack...@citrix.com>; Wei Liu > <wei.l...@citrix.com>; Stefano Stabellini <sstabell...@kernel.org>; xen- > de...@lists.xenproject.org; Tim (Xen.org) <t...@xen.org> > Subject: RE: [PATCH v14 07/11] x86/mm: add an extra command to > HYPERVISOR_mmu_update... > > >>> On 13.12.17 at 15:49, <paul.durr...@citrix.com> wrote: > >> From: Jan Beulich [mailto:jbeul...@suse.com] > >> Sent: 13 December 2017 14:36 > >> >>> On 13.12.17 at 13:06, <paul.durr...@citrix.com> wrote: > >> >> From: Jan Beulich [mailto:jbeul...@suse.com] > >> >> Sent: 12 December 2017 14:39 > >> >> >>> On 12.12.17 at 14:52, <andrew.coop...@citrix.com> 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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel