All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@arm.com>
To: Volodymyr Babchuk <volodymyr_babchuk@epam.com>,
	xen-devel@lists.xenproject.org, xen-devel@lists.xen.org
Cc: Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v2 05/13] optee: add fast calls handling
Date: Wed, 5 Sep 2018 14:36:42 +0100	[thread overview]
Message-ID: <667e115f-9fda-3b02-5397-cab0d780cf3e@arm.com> (raw)
In-Reply-To: <1535993677-20816-6-git-send-email-volodymyr_babchuk@epam.com>

Hi Volodymyr,

On 09/03/2018 05:54 PM, Volodymyr Babchuk wrote:
> Some fast SMCCC calls to OP-TEE should be handled in a special way.
> Capabilities exchange should be filtered out, so only caps
> known to mediator are used. Also mediator disables static SHM
> memory capability, because it can't share OP-TEE memory with a domain.
> Only domain can share memory with OP-TEE, so it ensures that OP-TEE
> supports dynamic SHM.
> 
> Basically, static SHM is a reserved memory region which is always
> mapped into OP-TEE address space. It belongs to OP-TEE. Normally,
> NW is allowed to access there, so it can communicate with OP-TEE.
> 
> On other hand, dynamic SHM is NW's own memory, which it can share
> with OP-TEE. OP-TEE maps this memory dynamically, when it wants to
> access it.s wo
> 
> Because mediator can't share one static SHM region with all guests,
> it just disables it for all.

Would it make sense to still allow the hardware domain to access static SHM?

> 
> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
> ---
>   xen/arch/arm/tee/optee.c | 56 +++++++++++++++++++++++++++++++++++++++++++++++-
>   1 file changed, 55 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c
> index 7bb84d9..48bff5d 100644
> --- a/xen/arch/arm/tee/optee.c
> +++ b/xen/arch/arm/tee/optee.c
> @@ -56,7 +56,7 @@ static int optee_enable(struct domain *d)
>       return 0;
>   }
>   
> -static void forward_call(struct cpu_user_regs *regs)
> +static bool forward_call(struct cpu_user_regs *regs)
>   {
>       struct arm_smccc_res resp;
>   
> @@ -79,6 +79,20 @@ static void forward_call(struct cpu_user_regs *regs)
>       set_user_reg(regs, 5, 0);
>       set_user_reg(regs, 6, 0);
>       set_user_reg(regs, 7, 0);
> +
> +    return resp.a0 == OPTEE_SMC_RETURN_OK;
> +}
> +
> +static void set_return(struct cpu_user_regs *regs, uint32_t ret)
> +{
> +    set_user_reg(regs, 0, ret);
> +    set_user_reg(regs, 1, 0);
> +    set_user_reg(regs, 2, 0);
> +    set_user_reg(regs, 3, 0);
> +    set_user_reg(regs, 4, 0);
> +    set_user_reg(regs, 5, 0);
> +    set_user_reg(regs, 6, 0);
> +    set_user_reg(regs, 7, 0);
>   }
>   
>   static void optee_domain_destroy(struct domain *d)
> @@ -92,6 +106,39 @@ static void optee_domain_destroy(struct domain *d)
>                     &resp);
>   }
>   
> +static bool handle_exchange_capabilities(struct cpu_user_regs *regs)
> +{
> +    uint32_t caps;
> +
> +    /* Filter out unknown guest caps */
> +    caps = get_user_reg(regs, 1);
> +    caps &= OPTEE_SMC_NSEC_CAP_UNIPROCESSOR;

I think it would make sense to introduce a define for the mask.

> +    set_user_reg(regs, 1, caps);
> +
> +    /* Forward call and return error (if any) back to the guest */
> +    if ( !forward_call(regs) )
> +        return true;
> +
> +    caps = get_user_reg(regs, 1);
> +
> +    /* Filter out unknown OP-TEE caps */
> +    caps &= OPTEE_SMC_SEC_CAP_HAVE_RESERVED_SHM |
> +        OPTEE_SMC_SEC_CAP_UNREGISTERED_SHM |
> +        OPTEE_SMC_SEC_CAP_DYNAMIC_SHM;

Same here.

> +
> +    /* Drop static SHM_RPC cap */
> +    caps &= ~OPTEE_SMC_SEC_CAP_HAVE_RESERVED_SHM;
> +
> +    /* Don't allow guests to work without dynamic SHM */
> +    if ( !(caps & OPTEE_SMC_SEC_CAP_DYNAMIC_SHM) ) {

Coding style.

if ( ... )
{

> +        set_return(regs, OPTEE_SMC_RETURN_ENOTAVAIL);
> +        return true;
> +    }
> +
> +    set_user_reg(regs, 1, caps);

Newline here.

> +    return true;
> +}
> +
>   static bool optee_handle_call(struct cpu_user_regs *regs)
>   {
>       switch ( get_user_reg(regs, 0) )
> @@ -103,10 +150,17 @@ static bool optee_handle_call(struct cpu_user_regs *regs)
>       case OPTEE_SMC_FUNCID_GET_OS_REVISION:
>       case OPTEE_SMC_ENABLE_SHM_CACHE:
>       case OPTEE_SMC_DISABLE_SHM_CACHE:
> +        forward_call(regs);
> +        return true;
>       case OPTEE_SMC_GET_SHM_CONFIG:
> +        /* No static SHM available for guests */
> +        set_return(regs, OPTEE_SMC_RETURN_ENOTAVAIL);
> +        return true;
>       case OPTEE_SMC_EXCHANGE_CAPABILITIES:
> +        return handle_exchange_capabilities(regs);
>       case OPTEE_SMC_CALL_WITH_ARG:
>       case OPTEE_SMC_CALL_RETURN_FROM_RPC:
> +        /* TODO: Add proper handling for this calls */

I think I would prefer if the call were not introduced in the first 
place. You then add call when they are actually implemented.

>           forward_call(regs);
>           return true;
>       default:
> 

Cheers,

-- 
Julien Grall

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

  reply	other threads:[~2018-09-05 13:36 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-03 16:54 [PATCH v2 00/13] TEE mediator (and OP-TEE) support in XEN Volodymyr Babchuk
2018-09-03 16:54 ` [PATCH v2 01/13] arm: add generic TEE mediator framework Volodymyr Babchuk
2018-09-03 17:22   ` Julien Grall
2018-09-03 16:54 ` [PATCH v2 02/13] domctl: add tee_op domctl Volodymyr Babchuk
2018-09-03 17:16   ` Julien Grall
2018-09-03 16:54 ` [PATCH v2 03/13] arm: tee: add OP-TEE header files Volodymyr Babchuk
2018-09-03 16:54 ` [PATCH v2 04/13] optee: add OP-TEE mediator skeleton Volodymyr Babchuk
2018-09-03 17:38   ` Julien Grall
2018-09-03 17:55     ` Volodymyr Babchuk
2018-09-04 19:48       ` Julien Grall
2018-09-05 12:17         ` Volodymyr Babchuk
2018-09-05 13:16           ` Julien Grall
2018-09-05 13:38             ` Volodymyr Babchuk
2018-09-05 13:47               ` Julien Grall
2018-09-03 16:54 ` [PATCH v2 05/13] optee: add fast calls handling Volodymyr Babchuk
2018-09-05 13:36   ` Julien Grall [this message]
2018-09-03 16:54 ` [PATCH v2 06/13] optee: add domain contexts Volodymyr Babchuk
2018-09-05 14:10   ` Julien Grall
2018-09-05 14:18     ` Andrew Cooper
2018-09-05 14:23     ` Volodymyr Babchuk
2018-09-05 14:27       ` Julien Grall
2018-09-03 16:54 ` [PATCH v2 07/13] optee: add std call handling Volodymyr Babchuk
2018-09-05 15:17   ` Julien Grall
2018-09-10 17:37     ` Volodymyr Babchuk
2018-09-11 11:19       ` Julien Grall
2018-09-11 11:31         ` Volodymyr Babchuk
2018-09-11 13:30           ` Julien Grall
2018-09-03 16:54 ` [PATCH v2 08/13] optee: add support for RPC SHM buffers Volodymyr Babchuk
2018-09-10 13:01   ` Julien Grall
2018-09-10 17:44     ` Volodymyr Babchuk
2018-09-11 11:53       ` Julien Grall
2018-09-11 19:30         ` Volodymyr Babchuk
2018-09-12 10:59           ` Julien Grall
2018-09-12 13:51             ` Volodymyr Babchuk
2018-09-18 16:11               ` Julien Grall
2018-09-03 16:54 ` [PATCH v2 09/13] optee: add support for arbitrary shared memory Volodymyr Babchuk
2018-09-10 14:02   ` Julien Grall
2018-09-10 18:04     ` Volodymyr Babchuk
2018-09-11 13:37       ` Julien Grall
2018-09-11 19:33         ` Volodymyr Babchuk
2018-09-12 11:02           ` Julien Grall
2018-09-12 12:45             ` Volodymyr Babchuk
2018-09-18 16:19               ` Julien Grall
2018-09-03 16:54 ` [PATCH v2 10/13] optee: add support for RPC commands Volodymyr Babchuk
2018-09-10 15:34   ` Julien Grall
2018-09-10 18:14     ` Volodymyr Babchuk
2018-09-11 13:56       ` Julien Grall
2018-09-11 18:58         ` Volodymyr Babchuk
2018-09-18 16:50           ` Julien Grall
2018-09-19 15:21             ` Volodymyr Babchuk
2018-09-03 16:54 ` [PATCH v2 11/13] libxc: add xc_dom_tee_enable(...) function Volodymyr Babchuk
2018-09-06 10:59   ` Wei Liu
2018-09-03 16:54 ` [PATCH v2 12/13] xl: add "tee" option for xl.cfg Volodymyr Babchuk
2018-09-11 14:23   ` Julien Grall
2018-09-03 16:54 ` [PATCH v2 13/13] lixl: arm: create optee firmware node in DT if tee=1 Volodymyr Babchuk
2018-09-11 14:48   ` 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=667e115f-9fda-3b02-5397-cab0d780cf3e@arm.com \
    --to=julien.grall@arm.com \
    --cc=sstabellini@kernel.org \
    --cc=volodymyr_babchuk@epam.com \
    --cc=xen-devel@lists.xen.org \
    --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.