lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHUa44G3jCqyiXtdZAAEw=8WPC+m5fD8tqsPfGc3MkV3JjRDCA@mail.gmail.com>
Date:   Tue, 7 Feb 2023 10:08:45 +0100
From:   Jens Wiklander <jens.wiklander@...aro.org>
To:     Sumit Garg <sumit.garg@...aro.org>
Cc:     Etienne Carriere <etienne.carriere@...aro.org>,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        Sudeep Holla <sudeep.holla@....com>,
        Cristian Marussi <cristian.marussi@....com>
Subject: Re: [PATCH 1/2] tee: system invocation

Hi,

On Tue, Feb 7, 2023 at 8:27 AM Sumit Garg <sumit.garg@...aro.org> wrote:
>
> Hi Etienne,
>
> On Mon, 30 Jan 2023 at 15:12, Etienne Carriere
> <etienne.carriere@...aro.org> wrote:
> >
> > Adds TEE context flag sys_service to be enabled for invocation contexts
> > that should used TEE provisioned system resources. OP-TEE SMC ABI entry
>
> s/used/use/
>
> > rely this information to use a dedicated entry function to request
> > allocation of a system thread from a dedicated system context pool.
> >
> > This feature is needed when a TEE invocation cannot afford to wait for
> > a free TEE thread when all TEE threads context are used and suspended
> > as these may be suspended waiting for a system service, as an SCMI clock
> > or voltage regulator, to be enabled. An example is when OP-TEE invokes
> > a Linux OS remove service (RPC) to access an eMMC RPMB partition and
>
> s/remove/remote/
>
> > the eMMC device is supplied by an OP-TEE SCMI regulator.
> >
> > Signed-off-by: Etienne Carriere <etienne.carriere@...aro.org>
> > ---
> >  drivers/tee/optee/optee_smc.h | 14 +++++++++++---
> >  drivers/tee/optee/smc_abi.c   |  6 +++++-
> >  include/linux/tee_drv.h       |  4 ++++
> >  3 files changed, 20 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/tee/optee/optee_smc.h b/drivers/tee/optee/optee_smc.h
> > index 73b5e7760d10..7c7eedf183c5 100644
> > --- a/drivers/tee/optee/optee_smc.h
> > +++ b/drivers/tee/optee/optee_smc.h
> > @@ -108,7 +108,8 @@ struct optee_smc_call_get_os_revision_result {
> >   * Call with struct optee_msg_arg as argument
> >   *
> >   * When called with OPTEE_SMC_CALL_WITH_RPC_ARG or
> > - * OPTEE_SMC_CALL_WITH_REGD_ARG in a0 there is one RPC struct optee_msg_arg
> > + * OPTEE_SMC_CALL_WITH_REGD_ARG or OPTEE_SMC_FUNCID_CALL_SYSTEM_WITH_REGD_ARG
> > + * in a0 there is one RPC struct optee_msg_arg
> >   * following after the first struct optee_msg_arg. The RPC struct
> >   * optee_msg_arg has reserved space for the number of RPC parameters as
> >   * returned by OPTEE_SMC_EXCHANGE_CAPABILITIES.
> > @@ -130,8 +131,8 @@ struct optee_smc_call_get_os_revision_result {
> >   * a4-6        Not used
> >   * a7  Hypervisor Client ID register
> >   *
> > - * Call register usage, OPTEE_SMC_CALL_WITH_REGD_ARG:
> > - * a0  SMC Function ID, OPTEE_SMC_CALL_WITH_REGD_ARG
> > + * Call register usage, OPTEE_SMC_CALL_WITH_REGD_ARG and OPTEE_SMC_FUNCID_CALL_SYSTEM_WITH_REGD_ARG:
> > + * a0  SMC Function ID, OPTEE_SMC_CALL_WITH_REGD_ARG or OPTEE_SMC_FUNCID_CALL_SYSTEM_WITH_REGD_ARG
> >   * a1  Upper 32 bits of a 64-bit shared memory cookie
> >   * a2  Lower 32 bits of a 64-bit shared memory cookie
> >   * a3  Offset of the struct optee_msg_arg in the shared memory with the
> > @@ -175,6 +176,8 @@ struct optee_smc_call_get_os_revision_result {
> >         OPTEE_SMC_STD_CALL_VAL(OPTEE_SMC_FUNCID_CALL_WITH_RPC_ARG)
> >  #define OPTEE_SMC_CALL_WITH_REGD_ARG \
> >         OPTEE_SMC_STD_CALL_VAL(OPTEE_SMC_FUNCID_CALL_WITH_REGD_ARG)
> > +#define OPTEE_SMC_CALL_SYSTEM_WITH_REGD_ARG \
> > +       OPTEE_SMC_STD_CALL_VAL(OPTEE_SMC_FUNCID_CALL_SYSTEM_WITH_REGD_ARG)
> >
> >  /*
> >   * Get Shared Memory Config
> > @@ -254,6 +257,8 @@ struct optee_smc_get_shm_config_result {
> >  #define OPTEE_SMC_SEC_CAP_ASYNC_NOTIF          BIT(5)
> >  /* Secure world supports pre-allocating RPC arg struct */
> >  #define OPTEE_SMC_SEC_CAP_RPC_ARG              BIT(6)
> > +/* Secure world provisions thread for system service invocation */
> > +#define OPTEE_SMC_SEC_CAP_SYSTEM_THREAD                BIT(7)
> >
> >  #define OPTEE_SMC_FUNCID_EXCHANGE_CAPABILITIES 9
> >  #define OPTEE_SMC_EXCHANGE_CAPABILITIES \
> > @@ -426,6 +431,9 @@ struct optee_smc_disable_shm_cache_result {
> >  /* See OPTEE_SMC_CALL_WITH_REGD_ARG above */
> >  #define OPTEE_SMC_FUNCID_CALL_WITH_REGD_ARG    19
> >
> > +/* See OPTEE_SMC_CALL_SYSTEM_WITH_REGD_ARG above */
> > +#define OPTEE_SMC_FUNCID_CALL_SYSTEM_WITH_REGD_ARG     20
> > +
> >  /*
> >   * Resume from RPC (for example after processing a foreign interrupt)
> >   *
> > diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c
> > index a1c1fa1a9c28..513038a138f6 100644
> > --- a/drivers/tee/optee/smc_abi.c
> > +++ b/drivers/tee/optee/smc_abi.c
> > @@ -889,7 +889,11 @@ static int optee_smc_do_call_with_arg(struct tee_context *ctx,
> >         }
> >
> >         if  (rpc_arg && tee_shm_is_dynamic(shm)) {
> > -               param.a0 = OPTEE_SMC_CALL_WITH_REGD_ARG;
> > +               if (ctx->sys_service &&
> > +                   (optee->smc.sec_caps & OPTEE_SMC_SEC_CAP_SYSTEM_THREAD))
> > +                       param.a0 = OPTEE_SMC_CALL_SYSTEM_WITH_REGD_ARG;
> > +               else
> > +                       param.a0 = OPTEE_SMC_CALL_WITH_REGD_ARG;
>
> This system thread flag should also be applicable to platforms without
> registered arguments support. IOW, we need similar equivalents for
> OPTEE_SMC_FUNCID_CALL_WITH_ARG and OPTEE_SMC_FUNCID_CALL_WITH_RPC_ARG
> too. So I would rather suggest that we add following flag to all 3
> call types:
>
> #define OPTEE_SMC_CALL_SYSTEM_THREAD_FLAG    0x8000

The main reason platforms don't support registered arguments is that
they haven't been updated since this was introduced. So if a platform
needs system threads it could update to use registered arguments too.
The Linux kernel already supports registered arguments. An advantage
with the current approach is that the ABI is easier to implement
since we have distinct SMC IDs for each function.

Cheers,
Jens

>
> -Sumit
>
> >                 reg_pair_from_64(&param.a1, &param.a2, (u_long)shm);
> >                 param.a3 = offs;
> >         } else {
> > diff --git a/include/linux/tee_drv.h b/include/linux/tee_drv.h
> > index 17eb1c5205d3..1ff292ba7679 100644
> > --- a/include/linux/tee_drv.h
> > +++ b/include/linux/tee_drv.h
> > @@ -47,6 +47,9 @@ struct tee_shm_pool;
> >   *              non-blocking in nature.
> >   * @cap_memref_null: flag indicating if the TEE Client support shared
> >   *                   memory buffer with a NULL pointer.
> > + * @sys_service: flag set by the TEE Client to indicate that it is part of
> > + *              a system service and that the TEE may use resources reserved
> > + *              for this.
> >   */
> >  struct tee_context {
> >         struct tee_device *teedev;
> > @@ -55,6 +58,7 @@ struct tee_context {
> >         bool releasing;
> >         bool supp_nowait;
> >         bool cap_memref_null;
> > +       bool sys_service;
> >  };
> >
> >  struct tee_param_memref {
> > --
> > 2.25.1
> >

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ