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

From: Paul Durrant <Paul.Durrant@citrix.com>
To: 'Jan Beulich' <JBeulich@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"Tim (Xen.org)" <tim@xen.org>,
	George Dunlap <George.Dunlap@citrix.com>,
	Ian Jackson <Ian.Jackson@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v14 07/11] x86/mm: add an extra command to HYPERVISOR_mmu_update...
Date: Wed, 13 Dec 2017 14:49:21 +0000	[thread overview]
Message-ID: <268adb4590bc43c0a98ab027cb4744fc@AMSPEX02CL03.citrite.net> (raw)
In-Reply-To: <5A3148D90200007800197298@prv-mh.provo.novell.com>

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: 13 December 2017 14:36
> To: Paul Durrant <Paul.Durrant@citrix.com>
> Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>; George Dunlap
> <George.Dunlap@citrix.com>; Ian Jackson <Ian.Jackson@citrix.com>; Wei Liu
> <wei.liu2@citrix.com>; Stefano Stabellini <sstabellini@kernel.org>; xen-
> devel@lists.xenproject.org; Tim (Xen.org) <tim@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.Durrant@citrix.com> wrote:
> >> From: Jan Beulich [mailto:JBeulich@suse.com]
> >> Sent: 12 December 2017 14:39
> >> >>> On 12.12.17 at 14:52, <andrew.cooper3@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