All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@linaro.org>
To: Ian Campbell <Ian.Campbell@eu.citrix.com>
Cc: paolo.valente@unimore.it, keir@xen.org,
	stefano.stabellini@eu.citrix.com, Ian.Jackson@eu.citrix.com,
	dario.faggioli@citrix.com, tim@xen.org, xen-devel@lists.xen.org,
	etrudeau@broadcom.com, JBeulich@suse.com,
	Arianna Avanzini <avanzini.arianna@gmail.com>,
	viktor.kleinik@globallogic.com
Subject: Re: [PATCH v3 2/5] arch, arm: add consistency checks to REMOVE p2m changes
Date: Fri, 21 Mar 2014 12:45:46 +0000	[thread overview]
Message-ID: <532C347A.4020701@linaro.org> (raw)
In-Reply-To: <1395405162.19839.25.camel@kazak.uk.xensource.com>

On 03/21/2014 12:32 PM, Ian Campbell wrote:
>> The toolstack will only provide the gfn, except for this
>> function.
> 
> memory_unmap should also only take a gfn, which Xen should lookup to get
> an mfn. Notice that on x86 the unmap case doesn't use the mfn argument
> and passes only a gfn to clear_mmio_p2m_entry.

The MFN argument is used to check if the domain has access to the
MFN(see iomem_access_permitted at the beginning of the case).

I think we should implement the behavior you described in the common
implementation.

> It's racy to have the toolstack provide it anyway.

>>>> Otherwise the toolstack may be able to remove any page as long as the
>>>> MFN is in the iomem permitted range.
>>>
>>> Can't it already do this through other paths?
>>>
>>> Maybe there is a security implication there, but I would hope that the
>>> two permissions were pretty closely linked.
>>
>> One the main problem is iomem range permitted won't be anymore in sync.
> 
> I don't think this is a big issue. Having permission to have a mapping
> does not necessarily imply having the actual mapping, if the toolstack
> wants to do it then let it.
> 
>> x86 at least check that the gfn is an MMIO. I think we can safely extend
>> to check that the GFN use the corresponding MFN.
>>
>> I don't agree to let the toolstack uses this DOMCTL to do remove any
>> page in the guess memory.
> 
> Well, it already can today AFAICS, via remove_from_physmap.

remove_from_physmap can't remove MMIO region. There is a specific check
in get_page_from_gfn for this purpose.

IHMO, memory_unmap should avoid to remove other region than MMIO. Mainly
because apply_p2m_changes might not remove every reference taken on a page.

-- 
Julien Grall

  reply	other threads:[~2014-03-21 12:45 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-15 20:11 [PATCH v3 0/5] Implement the XEN_DOMCTL_memory_mapping hypercall for ARM Arianna Avanzini
2014-03-15 20:11 ` [PATCH v3 1/5] arch, arm: domain build: allow access to I/O memory of mapped devices Arianna Avanzini
2014-03-15 21:30   ` Julien Grall
2014-03-15 20:11 ` [PATCH v3 2/5] arch, arm: add consistency checks to REMOVE p2m changes Arianna Avanzini
2014-03-15 22:19   ` Julien Grall
2014-03-15 22:36     ` Arianna Avanzini
2014-03-15 22:42       ` Julien Grall
2014-03-21 10:44   ` Ian Campbell
2014-03-21 11:51     ` Julien Grall
2014-03-21 11:54       ` Ian Campbell
2014-03-21 12:08         ` Julien Grall
2014-03-21 12:32           ` Ian Campbell
2014-03-21 12:45             ` Julien Grall [this message]
2014-03-21 14:09               ` Ian Campbell
2014-03-21 14:11                 ` Julien Grall
2014-03-15 20:11 ` [PATCH v3 3/5] xen, common: add the XEN_DOMCTL_memory_mapping hypercall Arianna Avanzini
2014-03-15 22:32   ` Julien Grall
2014-03-17  8:01   ` Jan Beulich
2014-03-15 20:11 ` [PATCH v3 4/5] tools, libxl: parse optional start gfn from the iomem config option Arianna Avanzini
2014-03-15 22:35   ` Julien Grall
2014-03-17 10:01     ` Dario Faggioli
2014-03-21 10:47       ` Ian Campbell
2014-03-17 12:24   ` Julien Grall
2014-03-21 10:54   ` Ian Campbell
2014-03-15 20:11 ` [PATCH v3 5/5] tools, libxl: handle the iomem parameter with the memory_mapping hcall Arianna Avanzini
2014-03-17 12:35   ` Julien Grall
2014-03-18 16:15     ` Arianna Avanzini
2014-03-18 21:01       ` Julien Grall

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=532C347A.4020701@linaro.org \
    --to=julien.grall@linaro.org \
    --cc=Ian.Campbell@eu.citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=avanzini.arianna@gmail.com \
    --cc=dario.faggioli@citrix.com \
    --cc=etrudeau@broadcom.com \
    --cc=keir@xen.org \
    --cc=paolo.valente@unimore.it \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=tim@xen.org \
    --cc=viktor.kleinik@globallogic.com \
    --cc=xen-devel@lists.xen.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.