> -----Original Message----- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 13 December 2017 14:36 > 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 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? Paul > Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
