Message ID | 20230130094157.1082712-1-etienne.carriere@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp2093253wrn; Mon, 30 Jan 2023 01:52:49 -0800 (PST) X-Google-Smtp-Source: AK7set9vywfOylpD4RyDzLSnAB8dqJKVInyPeTGjlAYxTn/DorFJqJ3TCh6eg6BqEoMrcO1Q2f8J X-Received: by 2002:aa7:de07:0:b0:4a2:1812:e062 with SMTP id h7-20020aa7de07000000b004a21812e062mr12843137edv.18.1675072369505; Mon, 30 Jan 2023 01:52:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675072369; cv=none; d=google.com; s=arc-20160816; b=hEEDzV8dE/yddMS7V8HUTs2J7X8j4wkGLkhLcUPdOYRWF4B9JDOX3LxQ9VVYIgfCsA LeD/k+OW+tauL/3/M9z2+2YcAEqgI6AUL6oFB80kSUAY8tAxgdZcVHOUTrugnPFGWUWw i0QVeF+yy8K7voPTUoahA6CFkyPynTA35Tb7RLPFzGt8o4fUUZ9YEMyk3A5CAo/QUIsk xR1+bBV/OX3k7fRBtKbGQvXdy+PamfXELTPHPWVAh/Lb2y9/uM4PYM99Q8v39OgPbAmp Jg/7lRU/sXNq+fLUN0whMVrrFhlGzI1uthmnBT1hyvYb1lWPl9SXKYDRdFT2UFgnhhBy 7T7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=A/fX6lK4kyxqMY7Pp3GDtdcgmqukLTrE8ke8XBHGOTA=; b=Aj5Wgk8Rx+SjQzYOa6R5TkMz0slk1EiIzreuBvflfYlIF/mmSh2hOzAMMdy1nIkMma KAjzkQ7pFvAQAFcyUC6kJXxyPuOLmXbW3w/Jy2TXKXXX9AGn8m5Dcn8WT23y74GuEywF r+6GFUOAE5uwS+AT7MbHL2VwqKijfJeM5y1HihZLnfksZTEviefgG2TD5IU+lhAnoLDl NG5qBoXbznkhAheWvnU0PnbhYhhqMbUsuRBAWZn2pz7jR05IRZk+SBYOiCPk4rAsGsYv O7SaMhbhHkMzEAFi5kbK1omKhG3Uha1Vo8ZEq9s5SgcihpRg/d/yL8lhC53LmbhYs3WA msMw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=ju53Vfro; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ka6-20020a170907920600b0087bd4e90784si10157995ejb.850.2023.01.30.01.52.25; Mon, 30 Jan 2023 01:52:49 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=ju53Vfro; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234539AbjA3JmS (ORCPT <rfc822;n2h9z4@gmail.com> + 99 others); Mon, 30 Jan 2023 04:42:18 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49178 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235507AbjA3JmM (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 30 Jan 2023 04:42:12 -0500 Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 491AA5589 for <linux-kernel@vger.kernel.org>; Mon, 30 Jan 2023 01:42:10 -0800 (PST) Received: by mail-wm1-x331.google.com with SMTP id k8-20020a05600c1c8800b003dc57ea0dfeso1581944wms.0 for <linux-kernel@vger.kernel.org>; Mon, 30 Jan 2023 01:42:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=A/fX6lK4kyxqMY7Pp3GDtdcgmqukLTrE8ke8XBHGOTA=; b=ju53VfroPlDppWOtB93M8K7Bqn1MGhyRPaPLLDed3/0mTJGYkaXIGQhCi4OW1Aiu+n aUbvQgFJJPHorz6OJMqr6SQWxAp/BsKQFAIDwBNgcxRpJMV8gS5uceWOS9/y3nXAPidd Mjq99Er6rI67wnQvnFXercYS0fBeYVoIVO7MWtDt/6U0oyOVfQeSSg9OfVQaGqDUW8S+ hU/qtPT+St+FS9nyrHax/BnCpMKqA/oRZ9D65oIiC8dhRvvynUtUvPQ1Jx9di1ANWZTK tKnoqwL7j/T9kWZUjqeG6DA1sOYU/ZO3BuRPozQjm0KOMkyJ+hCVvqKk0wFTZBcK1ejY DY8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=A/fX6lK4kyxqMY7Pp3GDtdcgmqukLTrE8ke8XBHGOTA=; b=wiry00rpnYReqBxbJfSR0s3gnTJmfIiByzxzEqLVZWzcTm1Cr1iujlAe0sUzvqGD4H NBsUfqER/CB7VCEI2kPwX0CCHrL0tyOognFTV3bS6RSTEJmxYZRp30S4rgL/K7A5u2y0 B+OpOyaBVn/HYi8Xza8opu5UyKKDJliizlIM0LPuC6vmx+55fm3nut7M71K/8VtKWD8a T18jYnoptwT3NHoU1C6LUGjOJkz6u1Fip1q7mATV8+fa/+ugAk2vTC9s3N2OoXVBLVjL MA4QUW2QLO/FU2dHZ8gngH8QIZ9IPYTg3fs+RVxDFFvkrHLB6xjrDWDIKBAgj6W3GHz2 GCDg== X-Gm-Message-State: AFqh2kpXHBWulh9MMIKPXmIEcdDKe5eyfCwj3aAwsUOiGMBQTBBP6Wew 1xfZQ8IuiBsrqu1/Ywk7bgyfaZSbYp/Dco23 X-Received: by 2002:a05:600c:3c92:b0:3d5:365b:773e with SMTP id bg18-20020a05600c3c9200b003d5365b773emr50188850wmb.39.1675071728384; Mon, 30 Jan 2023 01:42:08 -0800 (PST) Received: from lmecxl1178.lme.st.com ([80.215.193.251]) by smtp.gmail.com with ESMTPSA id i27-20020a05600c4b1b00b003dc54d9aeeasm3865606wmp.36.2023.01.30.01.42.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Jan 2023 01:42:07 -0800 (PST) From: Etienne Carriere <etienne.carriere@linaro.org> To: linux-kernel@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org, Jens Wiklander <jens.wiklander@linaro.org>, Sumit Garg <sumit.garg@linaro.org>, Sudeep Holla <sudeep.holla@arm.com>, Cristian Marussi <cristian.marussi@arm.com>, Etienne Carriere <etienne.carriere@linaro.org> Subject: [PATCH 1/2] tee: system invocation Date: Mon, 30 Jan 2023 10:41:56 +0100 Message-Id: <20230130094157.1082712-1-etienne.carriere@linaro.org> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1756440684994835873?= X-GMAIL-MSGID: =?utf-8?q?1756440684994835873?= |
Series |
[1/2] tee: system invocation
|
|
Commit Message
Etienne Carriere
Jan. 30, 2023, 9:41 a.m. UTC
Adds TEE context flag sys_service to be enabled for invocation contexts
that should used TEE provisioned system resources. OP-TEE SMC ABI entry
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
the eMMC device is supplied by an OP-TEE SCMI regulator.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.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(-)
Comments
On Mon, Jan 30, 2023 at 10:42 AM Etienne Carriere <etienne.carriere@linaro.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 > 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 > the eMMC device is supplied by an OP-TEE SCMI regulator. > > Signed-off-by: Etienne Carriere <etienne.carriere@linaro.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(-) Looks good to me. Thanks, Jens > > 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; > reg_pair_from_64(¶m.a1, ¶m.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 >
Hi Etienne, On Mon, 30 Jan 2023 at 15:12, Etienne Carriere <etienne.carriere@linaro.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@linaro.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 -Sumit > reg_pair_from_64(¶m.a1, ¶m.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 >
Hi, On Tue, Feb 7, 2023 at 8:27 AM Sumit Garg <sumit.garg@linaro.org> wrote: > > Hi Etienne, > > On Mon, 30 Jan 2023 at 15:12, Etienne Carriere > <etienne.carriere@linaro.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@linaro.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(¶m.a1, ¶m.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 > >
On Tue, 7 Feb 2023 at 14:38, Jens Wiklander <jens.wiklander@linaro.org> wrote: > > Hi, > > On Tue, Feb 7, 2023 at 8:27 AM Sumit Garg <sumit.garg@linaro.org> wrote: > > > > Hi Etienne, > > > > On Mon, 30 Jan 2023 at 15:12, Etienne Carriere > > <etienne.carriere@linaro.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@linaro.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. Are we hinting at deprecating reserved shared memory support? If yes, wouldn't it be better to be explicit about it with a boot time warning message about its deprecation? Otherwise it will be difficult to debug for the end user to find out why system thread support isn't activated. > 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. I see your point but my initial thought was that we don't end up making that list too large that it becomes cumbersome to maintain, involving all the combinatorial. -Sumit > > Cheers, > Jens > > > > > -Sumit > > > > > reg_pair_from_64(¶m.a1, ¶m.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 > > >
On Tue, Feb 7, 2023 at 10:52 AM Sumit Garg <sumit.garg@linaro.org> wrote: > > On Tue, 7 Feb 2023 at 14:38, Jens Wiklander <jens.wiklander@linaro.org> wrote: > > > > Hi, > > > > On Tue, Feb 7, 2023 at 8:27 AM Sumit Garg <sumit.garg@linaro.org> wrote: > > > > > > Hi Etienne, > > > > > > On Mon, 30 Jan 2023 at 15:12, Etienne Carriere > > > <etienne.carriere@linaro.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@linaro.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. > > Are we hinting at deprecating reserved shared memory support? If yes, > wouldn't it be better to be explicit about it with a boot time warning > message about its deprecation? > > Otherwise it will be difficult to debug for the end user to find out > why system thread support isn't activated. > > > 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. > > I see your point but my initial thought was that we don't end up > making that list too large that it becomes cumbersome to maintain, > involving all the combinatorial. You have a point. Etienne, do you think we could give it a try at https://github.com/OP-TEE/optee_os/pull/5789 to better see how this would play out? Cheers, Jens
Hello Sumit, Jens, On Tue, 7 Feb 2023 at 11:36, Jens Wiklander <jens.wiklander@linaro.org> wrote: > > On Tue, Feb 7, 2023 at 10:52 AM Sumit Garg <sumit.garg@linaro.org> wrote: > > > > On Tue, 7 Feb 2023 at 14:38, Jens Wiklander <jens.wiklander@linaro.org> wrote: > > > > > > Hi, > > > > > > On Tue, Feb 7, 2023 at 8:27 AM Sumit Garg <sumit.garg@linaro.org> wrote: > > > > > > > > Hi Etienne, > > > > > > > > On Mon, 30 Jan 2023 at 15:12, Etienne Carriere > > > > <etienne.carriere@linaro.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@linaro.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. > > > > Are we hinting at deprecating reserved shared memory support? If yes, > > wouldn't it be better to be explicit about it with a boot time warning > > message about its deprecation? > > > > Otherwise it will be difficult to debug for the end user to find out > > why system thread support isn't activated. > > > > > 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. > > > > I see your point but my initial thought was that we don't end up > > making that list too large that it becomes cumbersome to maintain, > > involving all the combinatorial. > > You have a point. Etienne, do you think we could give it a try at > https://github.com/OP-TEE/optee_os/pull/5789 to better see how this > would play out? > Indeed I miss that... With the patch proposed here, indeed if OP-TEE does not support dynamic shared memory then Linux will never use the provisioned TEE thread. This is weird as in such a case OP-TEE provisions resources that will never be used, which is the exact opposite goal of this feature. Verified on our qemu-arm setup. For simplicity, I think this system invocation should require OP-TEE supports dyn shm. If OP-TEE could know when Linux does not support TEE system invocation, then OP-TEE could let any invocation use these provisioned resources so that they are not wasted. I think a good way would be Linux to expose if it supports this capability, during capabilities exchange. Would you agree with this approach? Etienne > Cheers, > Jens
Hi Etienne, On Wed, Feb 08, 2023 at 06:09:17PM +0100, Etienne Carriere wrote: > Hello Sumit, Jens, > [snip] > > > > > > > > > > > > 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. > > > > > > Are we hinting at deprecating reserved shared memory support? If yes, > > > wouldn't it be better to be explicit about it with a boot time warning > > > message about its deprecation? > > > > > > Otherwise it will be difficult to debug for the end user to find out > > > why system thread support isn't activated. > > > > > > > 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. > > > > > > I see your point but my initial thought was that we don't end up > > > making that list too large that it becomes cumbersome to maintain, > > > involving all the combinatorial. > > > > You have a point. Etienne, do you think we could give it a try at > > https://github.com/OP-TEE/optee_os/pull/5789 to better see how this > > would play out? > > > > Indeed I miss that... > With the patch proposed here, indeed if OP-TEE does not support > dynamic shared memory then Linux will never use the provisioned TEE > thread. This is weird as in such a case OP-TEE provisions resources > that will never be used, which is the exact opposite goal of this > feature. Verified on our qemu-arm setup. > > For simplicity, I think this system invocation should require OP-TEE > supports dyn shm. It's not obvious to me that this will easier to implement and maintain. Looking at the code in optee_os it looks like using a flag bit as proposed by Sumit would be quite easy to handle. > > If OP-TEE could know when Linux does not support TEE system > invocation, then OP-TEE could let any invocation use these provisioned > resources so that they are not wasted. > I think a good way would be Linux to expose if it supports this > capability, during capabilities exchange. > Would you agree with this approach? No, I'm not so keen on adding that side effect to OPTEE_SMC_EXCHANGE_CAPABILITIES. The way you're describing the problem it sounds like it's a normal world problem to know how many system threads are needed. How about adding a fast call where normal world can request how many system threads should be reserved? If none are requested, none will be reserved. Cheers, Jens
Hi Jens, On Thu, 9 Feb 2023 at 08:14, Jens Wiklander <jens.wiklander@linaro.org> wrote: > > Hi Etienne, > > On Wed, Feb 08, 2023 at 06:09:17PM +0100, Etienne Carriere wrote: > > Hello Sumit, Jens, > > > [snip] > > > > > > > > > > > > > > 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. > > > > > > > > Are we hinting at deprecating reserved shared memory support? If yes, > > > > wouldn't it be better to be explicit about it with a boot time warning > > > > message about its deprecation? > > > > > > > > Otherwise it will be difficult to debug for the end user to find out > > > > why system thread support isn't activated. > > > > > > > > > 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. > > > > > > > > I see your point but my initial thought was that we don't end up > > > > making that list too large that it becomes cumbersome to maintain, > > > > involving all the combinatorial. > > > > > > You have a point. Etienne, do you think we could give it a try at > > > https://github.com/OP-TEE/optee_os/pull/5789 to better see how this > > > would play out? > > > > > > > Indeed I miss that... > > With the patch proposed here, indeed if OP-TEE does not support > > dynamic shared memory then Linux will never use the provisioned TEE > > thread. This is weird as in such a case OP-TEE provisions resources > > that will never be used, which is the exact opposite goal of this > > feature. Verified on our qemu-arm setup. > > > > For simplicity, I think this system invocation should require OP-TEE > > supports dyn shm. > > It's not obvious to me that this will easier to implement and maintain. > Looking at the code in optee_os it looks like using a flag bit as > proposed by Sumit would be quite easy to handle. OP-TEE could auto disable thread provis when dyn shm is disabled, right. Will it be sufficient? We will still face cases where an OP-TEE provisions thread but Linux kernel is not aware (older vanilla kernel used with a recent OP-TEE OS). Not much platforms are really affected I guess but those executing with pager in small RAMs where a 4kB thread context costs. > > > > > If OP-TEE could know when Linux does not support TEE system > > invocation, then OP-TEE could let any invocation use these provisioned > > resources so that they are not wasted. > > I think a good way would be Linux to expose if it supports this > > capability, during capabilities exchange. > > Would you agree with this approach? > > No, I'm not so keen on adding that side effect to > OPTEE_SMC_EXCHANGE_CAPABILITIES. It is a capability REE would exchanges with TEE. What kind of side effects do you fear? > > The way you're describing the problem it sounds like it's a normal world > problem to know how many system threads are needed. How about adding a > fast call where normal world can request how many system threads should > be reserved? If none are requested, none will be reserved. Well, could be. With caps exchange, we have an SMC funcID to REE to say to TEE: "reserved the default configured number of sys thread". I think it is simpler. With REE calling TEE to provision thread, we would need another call to release the reservation. Whe caps exchange, we have a single SMC to reconfig the negotiated caps. > > Cheers, > Jens
On Thu, 9 Feb 2023 at 09:11, Etienne Carriere <etienne.carriere@linaro.org> wrote: > > Hi Jens, > > > On Thu, 9 Feb 2023 at 08:14, Jens Wiklander <jens.wiklander@linaro.org> wrote: > > > > Hi Etienne, > > > > On Wed, Feb 08, 2023 at 06:09:17PM +0100, Etienne Carriere wrote: > > > Hello Sumit, Jens, > > > > > [snip] > > > > > > > > > > > > > > > > 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. > > > > > > > > > > Are we hinting at deprecating reserved shared memory support? If yes, > > > > > wouldn't it be better to be explicit about it with a boot time warning > > > > > message about its deprecation? > > > > > > > > > > Otherwise it will be difficult to debug for the end user to find out > > > > > why system thread support isn't activated. > > > > > > > > > > > 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. > > > > > > > > > > I see your point but my initial thought was that we don't end up > > > > > making that list too large that it becomes cumbersome to maintain, > > > > > involving all the combinatorial. > > > > > > > > You have a point. Etienne, do you think we could give it a try at > > > > https://github.com/OP-TEE/optee_os/pull/5789 to better see how this > > > > would play out? > > > > > > > > > > Indeed I miss that... > > > With the patch proposed here, indeed if OP-TEE does not support > > > dynamic shared memory then Linux will never use the provisioned TEE > > > thread. This is weird as in such a case OP-TEE provisions resources > > > that will never be used, which is the exact opposite goal of this > > > feature. Verified on our qemu-arm setup. > > > > > > For simplicity, I think this system invocation should require OP-TEE > > > supports dyn shm. > > > > It's not obvious to me that this will easier to implement and maintain. > > Looking at the code in optee_os it looks like using a flag bit as > > proposed by Sumit would be quite easy to handle. > > OP-TEE could auto disable thread provis when dyn shm is disabled, right. By the way, from OP-TEE OS, we have config switches for dyn-shm and system context provisioning. The latter could depend on the former so it's clear at build time when TEE can embed the capability. Br, etienne > Will it be sufficient? We will still face cases where an OP-TEE > provisions thread but Linux kernel is not aware (older vanilla kernel > used with a recent OP-TEE OS). Not much platforms are really affected > I guess but those executing with pager in small RAMs where a 4kB > thread context costs. > > (snip)
Hi, On Thu, Feb 09, 2023 at 09:11:53AM +0100, Etienne Carriere wrote: > Hi Jens, > > > On Thu, 9 Feb 2023 at 08:14, Jens Wiklander <jens.wiklander@linaro.org> wrote: > > > > Hi Etienne, > > > > On Wed, Feb 08, 2023 at 06:09:17PM +0100, Etienne Carriere wrote: > > > Hello Sumit, Jens, > > > > > [snip] > > > > > > > > > > > > > > > > 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. > > > > > > > > > > Are we hinting at deprecating reserved shared memory support? If yes, > > > > > wouldn't it be better to be explicit about it with a boot time warning > > > > > message about its deprecation? > > > > > > > > > > Otherwise it will be difficult to debug for the end user to find out > > > > > why system thread support isn't activated. > > > > > > > > > > > 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. > > > > > > > > > > I see your point but my initial thought was that we don't end up > > > > > making that list too large that it becomes cumbersome to maintain, > > > > > involving all the combinatorial. > > > > > > > > You have a point. Etienne, do you think we could give it a try at > > > > https://github.com/OP-TEE/optee_os/pull/5789 to better see how this > > > > would play out? > > > > > > > > > > Indeed I miss that... > > > With the patch proposed here, indeed if OP-TEE does not support > > > dynamic shared memory then Linux will never use the provisioned TEE > > > thread. This is weird as in such a case OP-TEE provisions resources > > > that will never be used, which is the exact opposite goal of this > > > feature. Verified on our qemu-arm setup. > > > > > > For simplicity, I think this system invocation should require OP-TEE > > > supports dyn shm. > > > > It's not obvious to me that this will easier to implement and maintain. > > Looking at the code in optee_os it looks like using a flag bit as > > proposed by Sumit would be quite easy to handle. > > OP-TEE could auto disable thread provis when dyn shm is disabled, right. > Will it be sufficient? We will still face cases where an OP-TEE > provisions thread but Linux kernel is not aware (older vanilla kernel > used with a recent OP-TEE OS). Not much platforms are really affected > I guess but those executing with pager in small RAMs where a 4kB > thread context costs. When you add exceptions you make it more complicated. Now we must remember to always use dyn shm if we are to succeed in configuring with system threads. What if both dyn shm and static shm is configured in OP-TEE, but the kernel only uses static shm? > > > If OP-TEE could know when Linux does not support TEE system > > > invocation, then OP-TEE could let any invocation use these provisioned > > > resources so that they are not wasted. > > > I think a good way would be Linux to expose if it supports this > > > capability, during capabilities exchange. > > > Would you agree with this approach? > > > > No, I'm not so keen on adding that side effect to > > OPTEE_SMC_EXCHANGE_CAPABILITIES. > > It is a capability REE would exchanges with TEE. > What kind of side effects do you fear? I was hoping to keep it stateless. One thing less to keep track of when handing over from a boot stage to the kernel. > > The way you're describing the problem it sounds like it's a normal world > > problem to know how many system threads are needed. How about adding a > > fast call where normal world can request how many system threads should > > be reserved? If none are requested, none will be reserved. > > Well, could be. With caps exchange, we have an SMC funcID to REE to > say to TEE: "reserved the default configured number of sys thread". I > think it is simpler. Until you realize the that the default number of system threads doesn't match what you need. > > With REE calling TEE to provision thread, we would need another call > to release the reservation. Whe caps exchange, we have a single SMC to > reconfig the negotiated caps. A single SMC with growing complexity in its arguments. Cheers, Jens
On Thu, 9 Feb 2023 at 10:19, Jens Wiklander <jens.wiklander@linaro.org> wrote: > > Hi, > > On Thu, Feb 09, 2023 at 09:11:53AM +0100, Etienne Carriere wrote: > > Hi Jens, > > > > > > On Thu, 9 Feb 2023 at 08:14, Jens Wiklander <jens.wiklander@linaro.org> wrote: > > > > > > Hi Etienne, > > > > > > On Wed, Feb 08, 2023 at 06:09:17PM +0100, Etienne Carriere wrote: > > > > Hello Sumit, Jens, > > > > > > > [snip] > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > Are we hinting at deprecating reserved shared memory support? If yes, > > > > > > wouldn't it be better to be explicit about it with a boot time warning > > > > > > message about its deprecation? > > > > > > > > > > > > Otherwise it will be difficult to debug for the end user to find out > > > > > > why system thread support isn't activated. > > > > > > > > > > > > > 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. > > > > > > > > > > > > I see your point but my initial thought was that we don't end up > > > > > > making that list too large that it becomes cumbersome to maintain, > > > > > > involving all the combinatorial. > > > > > > > > > > You have a point. Etienne, do you think we could give it a try at > > > > > https://github.com/OP-TEE/optee_os/pull/5789 to better see how this > > > > > would play out? > > > > > > > > > > > > > Indeed I miss that... > > > > With the patch proposed here, indeed if OP-TEE does not support > > > > dynamic shared memory then Linux will never use the provisioned TEE > > > > thread. This is weird as in such a case OP-TEE provisions resources > > > > that will never be used, which is the exact opposite goal of this > > > > feature. Verified on our qemu-arm setup. > > > > > > > > For simplicity, I think this system invocation should require OP-TEE > > > > supports dyn shm. > > > > > > It's not obvious to me that this will easier to implement and maintain. > > > Looking at the code in optee_os it looks like using a flag bit as > > > proposed by Sumit would be quite easy to handle. > > > > OP-TEE could auto disable thread provis when dyn shm is disabled, right. > > Will it be sufficient? We will still face cases where an OP-TEE > > provisions thread but Linux kernel is not aware (older vanilla kernel > > used with a recent OP-TEE OS). Not much platforms are really affected > > I guess but those executing with pager in small RAMs where a 4kB > > thread context costs. > > When you add exceptions you make it more complicated. Now we must > remember to always use dyn shm if we are to succeed in configuring with > system threads. What if both dyn shm and static shm is configured in > OP-TEE, but the kernel only uses static shm? > > > > > If OP-TEE could know when Linux does not support TEE system > > > > invocation, then OP-TEE could let any invocation use these provisioned > > > > resources so that they are not wasted. > > > > I think a good way would be Linux to expose if it supports this > > > > capability, during capabilities exchange. > > > > Would you agree with this approach? > > > > > > No, I'm not so keen on adding that side effect to > > > OPTEE_SMC_EXCHANGE_CAPABILITIES. > > > > It is a capability REE would exchanges with TEE. > > What kind of side effects do you fear? > > I was hoping to keep it stateless. One thing less to keep track of when > handing over from a boot stage to the kernel. Or from a kernel VM unload/reload. > > > > The way you're describing the problem it sounds like it's a normal world > > > problem to know how many system threads are needed. How about adding a > > > fast call where normal world can request how many system threads should > > > be reserved? If none are requested, none will be reserved. > > > > Well, could be. With caps exchange, we have an SMC funcID to REE to > > say to TEE: "reserved the default configured number of sys thread". I > > think it is simpler. > > Until you realize the that the default number of system threads doesn't > match what you need. Ok, I see your point. Indeed, Linux drivers requiring system context could issue a fastcall SMC to request dynamic provisioning of TEE context resources, and release their request upon driver unload. I agree it would better scale in the long term. I'll propose something in a v2. > > > > > With REE calling TEE to provision thread, we would need another call > > to release the reservation. Whe caps exchange, we have a single SMC to > > reconfig the negotiated caps. > > A single SMC with growing complexity in its arguments. :) fair. > > Cheers, > Jens
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; reg_pair_from_64(¶m.a1, ¶m.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 {