All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xenproject.org
Cc: Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v2 2/3] xen/pvh: check permissions when adding MMIO regions
Date: Wed, 21 Jan 2015 11:08:42 +0100	[thread overview]
Message-ID: <54BF7AAA.8090401@citrix.com> (raw)
In-Reply-To: <54BE9C35.7010800@citrix.com>

El 20/01/15 a les 19.19, Andrew Cooper ha escrit:
> On 20/01/15 17:05, Roger Pau Monne wrote:
>> Check that MMIO regions added to PVH Dom0 are allowed. Previously a PVH Dom0
>> would have access to the full MMIO range.
>>
>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
>> Cc: Jan Beulich <jbeulich@suse.com>
>> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
>> ---
>> Changes since v1:
>>  - Use the newly introduced p2m_access_t to set the access type.
>>  - Don't add a next label.
>> ---
>>  xen/arch/x86/domain_build.c | 17 +++++++++++++++--
>>  1 file changed, 15 insertions(+), 2 deletions(-)
>>
>> diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
>> index f687c78..41d2541 100644
>> --- a/xen/arch/x86/domain_build.c
>> +++ b/xen/arch/x86/domain_build.c
>> @@ -319,12 +319,25 @@ static __init void pvh_add_mem_mapping(struct domain *d, unsigned long gfn,
>>                                         unsigned long mfn, unsigned long nr_mfns)
>>  {
>>      unsigned long i;
>> +    mfn_t omfn;
>> +    p2m_type_t t;
>> +    p2m_access_t a;
>>      int rc;
>>  
>>      for ( i = 0; i < nr_mfns; i++ )
>>      {
>> -        if ( (rc = set_mmio_p2m_entry(d, gfn + i, _mfn(mfn + i),
>> -                                      p2m_get_hostp2m(d)->default_access)) )
>> +        if ( !iomem_access_permitted(d, mfn + i, mfn + i) ) {
>> +            omfn = get_gfn_query_unlocked(d, gfn + i, &t);
>> +            guest_physmap_remove_page(d, gfn + i, mfn_x(omfn), PAGE_ORDER_4K);
>> +            continue;
>> +        }
> 
> This suggests a design flaw (possibly pre-existing).  We should not be
> removing physmap entries in pvh_add_mem_mapping(), nor should we be a
> position to need to revoke physmap entries during domain build.
> 
> If there is anything needing revoking at this stage, it should not have
> been added earlier.  How did you come to introduce this code?

This code was introduced with the PVH Dom0 support series done by
Mukesh. Basically we let construct_dom0 build the physmap as it would be
done for a PV Dom0 (no holes at all, plain physmap from 0 to maxmem) and
then we punch the MMIO holes as needed. After punching the holes, we add
the leftover memory to the end of the memory map.

IMHO this seems better than having two different ways of building the
Dom0 memory map interleaved in the code, one for PV and one for PVH,
specially taking into account that the code in construct_dom0 is already
quite convoluted.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2015-01-21 10:08 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-20 17:05 [PATCH v2 0/3] xen/pvh: prevent Dom0 from accessing reserved MMIO regions Roger Pau Monne
2015-01-20 17:05 ` [PATCH v2 1/3] xen: allow set_mmio_p2m_entry to specify access type Roger Pau Monne
2015-01-21 11:10   ` Jan Beulich
2015-01-20 17:05 ` [PATCH v2 2/3] xen/pvh: check permissions when adding MMIO regions Roger Pau Monne
2015-01-20 18:19   ` Andrew Cooper
2015-01-21 10:08     ` Roger Pau Monné [this message]
2015-01-21 13:02       ` Andrew Cooper
2015-01-22 15:24     ` Tim Deegan
2015-01-21 11:14   ` Jan Beulich
2015-01-20 17:05 ` [PATCH v2 3/3] xen: prevent access to HPET from Dom0 Roger Pau Monne
2015-01-20 18:35   ` Andrew Cooper
2015-01-21 10:09     ` Roger Pau Monné
2015-01-21 11:08     ` Jan Beulich
2015-01-21 11:18   ` Jan Beulich

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=54BF7AAA.8090401@citrix.com \
    --to=roger.pau@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=jbeulich@suse.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.