Re: [Xen-devel] get_page_from_gfn() for foreign pages

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 01 March 2018 14:32
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: xen-devel (xen-devel@xxxxxxxxxxxxxxxxxxxx) <xen-
> devel@xxxxxxxxxxxxxxxxxxxx>
> Subject: RE: [Xen-devel] get_page_from_gfn() for foreign pages
> 
> >>> On 01.03.18 at 15:17, <Paul.Durrant@xxxxxxxxxx> wrote:
> >>  -----Original Message-----
> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> Sent: 01 March 2018 14:00
> >> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> >> Cc: xen-devel (xen-devel@xxxxxxxxxxxxxxxxxxxx) <xen-
> >> devel@xxxxxxxxxxxxxxxxxxxx>
> >> Subject: Re: [Xen-devel] get_page_from_gfn() for foreign pages
> >>
> >> >>> On 01.03.18 at 12:39, <Paul.Durrant@xxxxxxxxxx> wrote:
> >> > Whilst debugging my PV-IOMMU code I ran into an issue with
> >> > get_page_from_gfn(): It is failing when the gfn in question is actually a
> >> > grant map from another domain, and the reason for this is that
> >> get_page(page,
> >> > domain) explicitly fails if the page owner is not the domain specified to
> > the
> >> > call. However, I find that ARM implementation of get_page_from_gfn()
> has
> >> a
> >> > test for foreign p2m entries and completes successfully (by avoiding a
> call
> >> > to get_page() and instead calling page_get_owner_and_reference()
> >> directly).
> >> >
> >> > I can't think of any particular reason why, on x86, get_page_from_gfn()
> >> > should not work for foreign mapped or grant mapped pages. Does
> anyone
> >> know
> >> > why the restriction is there?
> >>
> >> What part of {,p2m_}get_page_from_gfn() are you referring to?
> >> p2m_get_page_from_gfn()'s fast path does what you want; it looks
> >> like the slow path was wrongly ignored in 50fe6e7370 ("pvh dom0:
> >> add and remove foreign pages"). Or are you thinking about this for
> >> a PV domain (and hence you look at the second half of
> >> get_page_from_gfn())?
> >
> > Yes, it's the PV case I'm hitting, i.e:
> >
> > page = __mfn_to_page(gfn);
> > return mfn_valid(_mfn(gfn)) && get_page(page, d) ? page : NULL;
> >
> > In my particular case I have an mfn but it represents a page that dom0 has
> > grant mapped. When I come to look it up as a GFN with DOMID_SELF I get
> the
> > error.
> 
> Sure, and the problem is that for PV there's no P2M type associated
> with a page, so we can't know whether the page is legitimately
> foreign to the given domain, or a random page belonging to a
> domain the requesting one has no privilege over.

OK, so it's the lack of ability to check the P2M that is crucial. Would it not 
be sufficient to determine whether the specified domain has privilege over the 
page owner if they are not identical? (I can't remember whether there are any 
examples left of pages owned by a target that are not suitable for priv 
mapping... IIRC you cleaned up all the instances that left Xen vulnerable).

> 
> >> For grant mapped pages the situation may be a little less clear:
> >> How would you deal with a grant being revoked when you have
> >> random uses of the page in another domain?
> >>
> >
> > I suppose it comes down to whether we want to be able to have domA
> (which
> > has priv mapping rights over domB) to be able to take a ref on a page from
> > domC that was granted to domB. If, for example, you have a stubdom with
> a PV
> > backend for a framebuffer which is then exported via a VNC server running
> in
> > dom0 then that's exactly what you'd probably want to set up. So I don't see
> > why it should be disallowed. In my case domA == domB and it certainly
> seems
> > reasonable to me that a domain be able to page references on GFNs in its
> own
> > P2M regardless of the actual page owner.
> 
> There may be special cases where it is okay to be allowed, but in
> the general case it has to be refused. The grant table interface
> allows a guest to specify _exactly_ which domain(s) get(s) granted
> access to a given page. Part of me is actually thinking that even
> transitive grants already violate the trust put in the backend by a
> frontend.
> 
> And then you didn't really answer my question.

Well, you can't revoke a grant whist a backend has it mapped... that's been a 
limitation forever. Also, I think it's reasonable that granting to a domain A 
allows domain A *and* any other domain with mapping privilege over domain A to 
access that page. I don't think there's really any expectation in the grant 
interface that granting to only that domain... frontends have to trust backends 
and if the backend grants it on then so be it. That's certainly the level of 
trust that's been in place since v2 and AFAIK no-one is unhappy about that.

  Paul

> 
> Jan


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