All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@linaro.org>
To: Tamas K Lengyel <tklengyel@sec.in.tum.de>, xen-devel@lists.xen.org
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	tim@xen.org, stefano.stabellini@citrix.com, jbeulich@suse.com,
	keir@xen.org
Subject: Re: [PATCH V13 3/7] xen/arm: Allow hypervisor access to mem_access protected pages
Date: Thu, 12 Mar 2015 13:24:18 +0000	[thread overview]
Message-ID: <55019382.4040108@linaro.org> (raw)
In-Reply-To: <1425677073-13729-4-git-send-email-tklengyel@sec.in.tum.de>

Hi Tamas,

On 06/03/15 21:24, Tamas K Lengyel wrote:
> The guestcopy helpers use the MMU to verify that the given guest has read/write
> access to a given page during hypercalls. As we may have custom mem_access
> permissions set on these pages, we do a software-based type checking in case
> the MMU based approach failed, but only if mem_access_enabled is set.
> 
> These memory accesses are not forwarded to the mem_event listener. Accesses
> performed by the hypervisor are currently not part of the mem_access scheme.
> This is consistent behaviour with the x86 side as well.
> 
> Signed-off-by: Tamas K Lengyel <tklengyel@sec.in.tum.de>
> ---
> v12: - Check for mfn_valid as well.
> ---
>  xen/arch/arm/guestcopy.c | 124 +++++++++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 121 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
> index 7dbaeca..d42a469 100644
> --- a/xen/arch/arm/guestcopy.c
> +++ b/xen/arch/arm/guestcopy.c
> @@ -6,6 +6,115 @@
>  
>  #include <asm/mm.h>
>  #include <asm/guest_access.h>
> +#include <asm/p2m.h>
> +
> +/*
> + * If mem_access is in use it might have been the reason why get_page_from_gva
> + * failed to fetch the page, as it uses the MMU for the permission checking.
> + * Only in these cases we do a software-based type check and fetch the page if
> + * we indeed found a conflicting mem_access setting.
> + */
> +static int check_type_get_page(vaddr_t gva, unsigned long flag,
> +                               struct page_info** page)
> +{
> +    long rc;

AFAICT, all the return value stored in rc are int.

> +    paddr_t ipa;
> +    unsigned long maddr;
> +    unsigned long mfn;
> +    xenmem_access_t xma;
> +    p2m_type_t t;
> +
> +    rc = gva_to_ipa(gva, &ipa);
> +    if ( rc < 0 )
> +        return rc;
> +
> +    /*
> +     * We do this first as this is faster in the default case when no
> +     * permission is set on the page.
> +     */
> +    rc = p2m_get_mem_access(current->domain, paddr_to_pfn(ipa), &xma);
> +    if ( rc < 0 )

Maybe a likely would be good here?

> +        return rc;
> +
> +    /* Let's check if mem_access limited the access. */
> +    switch ( xma )
> +    {
> +    default:
> +    case XENMEM_access_rwx:
> +    case XENMEM_access_rw:
> +        return -EFAULT;
> +    case XENMEM_access_n2rwx:
> +    case XENMEM_access_n:
> +    case XENMEM_access_x:
> +        break;
> +    case XENMEM_access_wx:
> +    case XENMEM_access_w:
> +        if ( flag == GV2M_READ )
> +            break;
> +        else return -EFAULT;
> +    case XENMEM_access_rx2rw:
> +    case XENMEM_access_rx:
> +    case XENMEM_access_r:
> +        if ( flag == GV2M_WRITE )
> +            break;
> +        else return -EFAULT;
> +    }
> +
> +    /*
> +     * We had a mem_access permission limiting the access, but the page type
> +     * could also be limiting, so we need to check that as well.
> +     */
> +    maddr = p2m_lookup(current->domain, ipa, &t);
> +    if ( maddr == INVALID_PADDR )
> +        return -EFAULT;
> +
> +    mfn = maddr >> PAGE_SHIFT;
> +    if ( !mfn_valid(mfn) )
> +        return -EFAULT;
> +
> +    /*
> +     * All page types are readable so we only have to check the
> +     * type if writing.
> +     */

That's may change in the future. A white-list may be better in order to
avoid giving wrong access when a new p2m type is added.

> +    if ( flag == GV2M_WRITE )
> +    {
> +        switch ( t )
> +        {
> +        case p2m_ram_rw:

> +        case p2m_iommu_map_rw:
> +        case p2m_map_foreign:
> +        case p2m_grant_map_rw:
> +        case p2m_mmio_direct:

We disallow guest copy from the above 4 types via get_page_from_gva. So
I'm not sure if it's worth to check them here.

Regards,

-- 
Julien Grall

  parent reply	other threads:[~2015-03-12 13:24 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-06 21:24 [PATCH V13 0/7] Mem_access for ARM Tamas K Lengyel
2015-03-06 21:24 ` [PATCH V13 1/7] xen/arm: p2m changes for mem_access support Tamas K Lengyel
2015-03-11 16:07   ` Stefano Stabellini
2015-03-11 17:05     ` Tamas K Lengyel
2015-03-12 11:27   ` Ian Campbell
2015-03-12 12:22     ` Tamas K Lengyel
2015-03-12 13:53       ` Ian Campbell
2015-03-12 12:57   ` Julien Grall
2015-03-12 13:18     ` Tamas K Lengyel
2015-03-12 13:25       ` Julien Grall
2015-03-12 13:55         ` Ian Campbell
2015-03-12 13:56     ` Ian Campbell
2015-03-12 14:10       ` Andrew Cooper
2015-03-12 16:56         ` Julien Grall
2015-03-12 17:11           ` Ian Campbell
2015-03-06 21:24 ` [PATCH V13 2/7] xen/arm: Implement domain_get_maximum_gpfn Tamas K Lengyel
2015-03-11 15:43   ` Stefano Stabellini
2015-03-06 21:24 ` [PATCH V13 3/7] xen/arm: Allow hypervisor access to mem_access protected pages Tamas K Lengyel
2015-03-12 12:08   ` Ian Campbell
2015-03-12 12:31     ` Tamas K Lengyel
2015-03-12 13:24   ` Julien Grall [this message]
2015-03-12 13:38     ` Tamas K Lengyel
2015-03-12 13:43       ` Julien Grall
2015-03-12 14:33         ` Tamas K Lengyel
2015-03-12 13:50   ` Julien Grall
2015-03-12 14:13     ` Tamas K Lengyel
2015-03-12 14:52       ` Julien Grall
2015-03-12 15:27         ` Ian Campbell
2015-03-12 15:40           ` Julien Grall
2015-03-12 15:44             ` Tamas K Lengyel
2015-03-12 15:56               ` Ian Campbell
2015-03-12 16:02                 ` Tamas K Lengyel
2015-03-12 16:48                   ` Ian Campbell
2015-03-12 16:55                     ` Tamas K Lengyel
2015-03-12 15:54             ` Ian Campbell
2015-03-12 15:41           ` Tamas K Lengyel
2015-03-12 15:55             ` Ian Campbell
2015-03-12 16:10               ` Tamas K Lengyel
2015-03-06 21:24 ` [PATCH V13 4/7] xen/arm: Data abort exception (R/W) mem_events Tamas K Lengyel
2015-03-12 13:35   ` Ian Campbell
2015-03-12 15:13     ` Tamas K Lengyel
2015-03-12 15:19       ` Tamas K Lengyel
2015-03-12 15:24         ` Julien Grall
2015-03-12 15:35         ` Ian Campbell
2015-03-12 16:35           ` Julien Grall
2015-03-12 15:30       ` Ian Campbell
2015-03-12 15:13   ` Julien Grall
2015-03-12 15:26     ` Tamas K Lengyel
2015-03-12 15:37       ` Julien Grall
2015-03-12 15:46         ` Ian Campbell
2015-03-12 16:54           ` Julien Grall
2015-03-06 21:24 ` [PATCH V13 5/7] xen/arm: Instruction prefetch abort (X) mem_event handling Tamas K Lengyel
2015-03-23 14:32   ` Tamas K Lengyel
2015-03-23 15:15     ` Ian Campbell
2015-03-23 15:18       ` Ian Campbell
2015-03-23 15:47         ` Tamas K Lengyel
2015-03-23 16:22           ` Ian Campbell
2015-03-23 16:47             ` Tamas K Lengyel
2015-03-24 13:06               ` Tamas K Lengyel
2015-03-26 10:50                 ` Ian Campbell
2015-03-26 11:24                   ` Tamas K Lengyel
2015-03-26 11:53                     ` Ian Campbell
2015-03-06 21:24 ` [PATCH V13 6/7] xen/arm: Enable mem_access on ARM Tamas K Lengyel
2015-03-12 13:36   ` Ian Campbell
2015-03-12 15:19   ` Julien Grall
2015-03-12 15:43     ` Tamas K Lengyel
2015-03-06 21:24 ` [PATCH V13 7/7] tools/libxc: Allocate magic page for mem access " Tamas K Lengyel
2015-03-12 13:36   ` Ian Campbell
2015-03-12 11:30 ` [PATCH V13 0/7] Mem_access for ARM Ian Campbell
2015-03-12 12:24   ` Tamas K Lengyel
2015-03-12 13:53     ` Ian Campbell

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=55019382.4040108@linaro.org \
    --to=julien.grall@linaro.org \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=keir@xen.org \
    --cc=stefano.stabellini@citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=tim@xen.org \
    --cc=tklengyel@sec.in.tum.de \
    --cc=wei.liu2@citrix.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.