From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH v7 10/10] xen/common: do not implicitly permit access to mapped I/O memory Date: Mon, 26 May 2014 12:24:42 +0100 Message-ID: <5383247A.60900@linaro.org> References: <1399305254-3695-1-git-send-email-avanzini.arianna@gmail.com> <1399305254-3695-11-git-send-email-avanzini.arianna@gmail.com> <5368C22B020000780000F3C9@mail.emea.novell.com> <53822511.1040604@linaro.org> <53831F6502000078000159F6@mail.emea.novell.com> <538330420200007800015B2B@mail.emea.novell.com> <53831D36.9070605@linaro.org> <53833E190200007800015BE0@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <53833E190200007800015BE0@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Arianna Avanzini Cc: Ian.Campbell@eu.citrix.com, paolo.valente@unimore.it, keir@xen.org, stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com, dario.faggioli@citrix.com, Ian.Jackson@eu.citrix.com, xen-devel@lists.xen.org, julien.grall@citrix.com, etrudeau@broadcom.com, tim@xen.org, viktor.kleinik@globallogic.com List-Id: xen-devel@lists.xenproject.org On 26/05/14 12:14, Jan Beulich wrote: >>>> On 26.05.14 at 12:53, wrote: > >> >> On 26/05/14 11:14, Jan Beulich wrote: >>> >>> Or maybe I wasn't wrong - the patch context doesn't really make >>> clear whether it's the granting or mapping operation that gets >>> adjusted here (since an earlier patch moved the mapping one into >>> this function). >> >> ret = -EPERM; >> - if ( !iomem_access_permitted(current->domain, mfn, mfn_end) ) >> + if ( !iomem_access_permitted(d, mfn, mfn_end) ) >> break; >> >> ret = xsm_iomem_mapping(XSM_HOOK, d, mfn, mfn_end, add); >> >> There is an xsm_iomem_mapping just after, so the change has been done in >> XEN_DOMCTL_memory_mapping. > > In which case I indeed stick to my original comment - it's perhaps > best to check _both_. Why? We may want to map the region in the guest P2M without giving the permission to the guest (I'm thinking about ARM passthrough case). With your requirements, we have to call 2 hypercalls rather than one for memory mapping, even if we don't want to allow the guest modifying iomem range. Regards, -- Julien Grall