get_page_from_gfn() for foreign pages

get_page_from_gfn() for foreign pages

[Paul Durrant]

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?

  Cheers,

    Paul

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

Re: get_page_from_gfn() for foreign pages

[Jan Beulich]

>>> On 01.03.18 at 12:39, <Paul.Durrant@citrix.com> 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())?

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?

Jan


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

Re: get_page_from_gfn() for foreign pages

[Paul Durrant]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: 01 March 2018 14:00
> To: Paul Durrant <Paul.Durrant@citrix.com>
> Cc: xen-devel (xen-devel@lists.xenproject.org) <xen-
> devel@lists.xenproject.org>
> Subject: Re: [Xen-devel] get_page_from_gfn() for foreign pages
> 
> >>> On 01.03.18 at 12:39, <Paul.Durrant@citrix.com> 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.

> 
> 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.

  Paul

> Jan


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

Re: get_page_from_gfn() for foreign pages

[Jan Beulich]

>>> On 01.03.18 at 15:17, <Paul.Durrant@citrix.com> wrote:
>>  -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: 01 March 2018 14:00
>> To: Paul Durrant <Paul.Durrant@citrix.com>
>> Cc: xen-devel (xen-devel@lists.xenproject.org) <xen-
>> devel@lists.xenproject.org>
>> Subject: Re: [Xen-devel] get_page_from_gfn() for foreign pages
>> 
>> >>> On 01.03.18 at 12:39, <Paul.Durrant@citrix.com> 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.

>> 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.

Jan


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

Re: get_page_from_gfn() for foreign pages

[Paul Durrant]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: 01 March 2018 14:32
> To: Paul Durrant <Paul.Durrant@citrix.com>
> Cc: xen-devel (xen-devel@lists.xenproject.org) <xen-
> devel@lists.xenproject.org>
> Subject: RE: [Xen-devel] get_page_from_gfn() for foreign pages
> 
> >>> On 01.03.18 at 15:17, <Paul.Durrant@citrix.com> wrote:
> >>  -----Original Message-----
> >> From: Jan Beulich [mailto:JBeulich@suse.com]
> >> Sent: 01 March 2018 14:00
> >> To: Paul Durrant <Paul.Durrant@citrix.com>
> >> Cc: xen-devel (xen-devel@lists.xenproject.org) <xen-
> >> devel@lists.xenproject.org>
> >> Subject: Re: [Xen-devel] get_page_from_gfn() for foreign pages
> >>
> >> >>> On 01.03.18 at 12:39, <Paul.Durrant@citrix.com> 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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: get_page_from_gfn() for foreign pages

[Jan Beulich]

>>> On 01.03.18 at 15:49, <Paul.Durrant@citrix.com> wrote:
>>  -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: 01 March 2018 14:32
>> >>> On 01.03.18 at 15:17, <Paul.Durrant@citrix.com> wrote:
>> > 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?

That could work, if you can live with the restriction that for a PV
target only Dom0 can have privilege over it (for HVM it could also
be a stubdom).

> (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).

I think so, yes.

>> >> 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.

All true, but what you want to do here is a mapping outside of
what grant_table.c controls and provides. Yet for the page owner
to know when a grant is fine to revoke, such obtaining of extra
references would need to be tracked.

Jan


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

Re: get_page_from_gfn() for foreign pages

[Paul Durrant]

> -----Original Message-----
[snip]
> >> 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.
> 
> All true, but what you want to do here is a mapping outside of
> what grant_table.c controls and provides. Yet for the page owner
> to know when a grant is fine to revoke, such obtaining of extra
> references would need to be tracked.
> 

Ah yes, that's a bit gnarly. I'll have to try to figure out what can be done there.

  Paul

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