All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>, Paul Durrant <paul.durrant@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Jackson <ian.jackson@eu.citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v14 07/11] x86/mm: add an extra command to HYPERVISOR_mmu_update...
Date: Tue, 12 Dec 2017 13:52:54 +0000	[thread overview]
Message-ID: <12625ce1-047a-22b9-d196-37dbc5361060@citrix.com> (raw)
In-Reply-To: <5A2FE6C00200007800196D55@prv-mh.provo.novell.com>

On 12/12/17 13:25, Jan Beulich wrote:
>>>> On 28.11.17 at 16:08, <paul.durrant@citrix.com> wrote:
>> @@ -1905,7 +1906,8 @@ static int mod_l1_entry(l1_pgentry_t *pl1e, l1_pgentry_t nl1e,
>>          }
>>  
>>          /* Translate foreign guest address. */
>> -        if ( paging_mode_translate(pg_dom) )
>> +        if ( cmd != MMU_PT_UPDATE_NO_TRANSLATE &&
>> +             paging_mode_translate(pg_dom) )
>>          {
>>              p2m_type_t p2mt;
>>              p2m_query_t q = l1e_get_flags(nl1e) & _PAGE_RW ?
> Now that they're public - it was this change which led to the
> recognition of the issue XSA-248 describes (which in turn led to the
> other three). Without the fix for XSA-248 you'd have introduced a
> worse issue here, allowing writable mappings of page table pages
> rather than just r/o ones (leading to hypervisor crashes).
>
> Especially with the bypass of acquiring a writable page ref in
> get_page_from_l1e() for domains controlling shadow-external
> domains we need to be extremely careful with assigning page
> ownership. Before this series goes in I'd therefor like to ask you and
> others (especially people on the Cc list) to double check that the
> bypass introduced above doesn't allow for other (security) badness.
> I think I've sufficiently convinced myself that it doesn't, but this
> clearly wants double checking.

Perhaps it is worth stepping back and considering the usecase from first
principles.

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.

On top of that, it would be far more simple if the mechanism by which
this is achieved was compatible with the existing mapping interfaces. 
One way or another, a PV guest needs to be able to construct a PTE for
these frames, and HVM guests need to be able to add these frames to its
physmap, and this looks very similar to foreign mapping.

Other thoughts/suggestions welcome.

~Andrew

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

  reply	other threads:[~2017-12-12 13:53 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-28 15:08 [PATCH v14 00/11] x86: guest resource mapping Paul Durrant
2017-11-28 15:08 ` [PATCH v14 01/11] x86/hvm/ioreq: maintain an array of ioreq servers rather than a list Paul Durrant
2017-11-28 15:08 ` [PATCH v14 02/11] x86/hvm/ioreq: simplify code and use consistent naming Paul Durrant
2017-11-28 15:08 ` [PATCH v14 03/11] x86/hvm/ioreq: use gfn_t in struct hvm_ioreq_page Paul Durrant
2017-11-28 15:08 ` [PATCH v14 04/11] x86/hvm/ioreq: defer mapping gfns until they are actually requsted Paul Durrant
2017-12-06 21:49   ` Chao Gao
2017-12-07  8:38     ` Paul Durrant
2017-11-28 15:08 ` [PATCH v14 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources Paul Durrant
2017-11-28 18:50   ` Daniel De Graaf
2017-11-28 15:08 ` [PATCH v14 06/11] x86/hvm/ioreq: add a new mappable resource type Paul Durrant
2017-12-14  9:51   ` Paul Durrant
2017-12-14  9:52     ` Paul Durrant
2017-12-14 10:31     ` Paul Durrant
2017-12-14 13:46     ` Jan Beulich
2017-12-14 13:46       ` Paul Durrant
2017-11-28 15:08 ` [PATCH v14 07/11] x86/mm: add an extra command to HYPERVISOR_mmu_update Paul Durrant
2017-12-12 13:25   ` Jan Beulich
2017-12-12 13:52     ` Andrew Cooper [this message]
2017-12-12 14:38       ` Jan Beulich
2017-12-13 12:06         ` Paul Durrant
2017-12-13 14:35           ` Jan Beulich
2017-12-13 14:49             ` Paul Durrant
2017-12-13 15:24               ` Jan Beulich
2017-12-13 17:03                 ` Paul Durrant
2017-12-14 13:50                   ` Jan Beulich
2017-12-12 14:54     ` Paul Durrant
2017-11-28 15:08 ` [PATCH v14 08/11] tools/libxenforeignmemory: add support for resource mapping Paul Durrant
2017-11-28 15:08 ` [PATCH v14 09/11] tools/libxenforeignmemory: reduce xenforeignmemory_restrict code footprint Paul Durrant
2017-11-28 15:08 ` [PATCH v14 10/11] common: add a new mappable resource type: XENMEM_resource_grant_table Paul Durrant
2017-11-28 15:08 ` [PATCH v14 11/11] tools/libxenctrl: use new xenforeignmemory API to seed grant table Paul Durrant

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=12625ce1-047a-22b9-d196-37dbc5361060@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=paul.durrant@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=tim@xen.org \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.