[BCC all OP-TEE maintainers]
Hi OP-TEE maintainers & contributors,
OP-TEE v3.16.0 is scheduled to be released on 2022-01-28. So, now is a
good time to start testing the master branch on the various platforms
and report/fix any bugs.
The GitHub pull request for collecting Tested-by tags or any other
comments is https://github.com/OP-TEE/optee_os/pull/5094
As usual, we will create a release candidate tag one week before the
release date for final testing.
In addition to that you can find some additional information related
to releases here:
https://optee.readthedocs.io/en/latest/general/releases.html
Thanks,
Jens
The addition of a shutdown hook by commit f25889f93184 ("optee:
fix tee out of memory failure seen during kexec reboot") introduced a
kernel shutdown regression that can be triggered after running the
xtest suites.
Once the shutdown hook is called it is not possible to communicate any
more with the supplicant process because the system is not scheduling
task any longer. Thus if the optee driver shutdown path receives a
supplicant RPC request from the OP-TEE we will deadlock the kernel's
shutdown.
This unexpected event will in fact occur after the xtest suite has
been run. It seems some cached SHM kept alive a context object which
in turn kept alive a session towards a PTA or TA. Closing the session
results in a socket RPC command being sent back from OP-TEE.
This sequence of events is captured by a 5.15 kernel annotated with
extra prints:
Calling OPTEE_SMC_DISABLE_SHM_CACHE
OPTEE_SMC_DISABLE_SHM_CACHE returned 0
freeing SHM ptr 0xFFFFFF8001079380
Calling OPTEE_SMC_DISABLE_SHM_CACHE
OPTEE_SMC_DISABLE_SHM_CACHE returned 0
freeing SHM ptr 0xFFFFFF8001CC5580
Calling OPTEE_SMC_DISABLE_SHM_CACHE
OPTEE_SMC_DISABLE_SHM_CACHE returned 0
freeing SHM ptr 0xFFFFFF8006308A80
Calling OPTEE_SMC_DISABLE_SHM_CACHE
OPTEE_SMC_DISABLE_SHM_CACHE returned 0
freeing SHM ptr 0xFFFFFF8006308B00
optee: optee_handle_rpc: a0=0XFFFF0000 a1=0XA0 a2=0X0
optee: optee_handle_rpc: a0=0XFFFF0005 a1=0XFFFFFF80 a2=0X61E6500
optee: handle_rpc_func_cmd: cmd = 0XA
optee_supp_thrd_req: func=0XA
Introduce a shutdown state in the optee device object to return an
immediate error to all RPC requests in the shutdown path.
Fixes: f25889f93184 ("optee: fix tee out of memory failure seen during kexec reboot
Signed-off-by: Lars Persson <larper(a)axis.com>
---
drivers/tee/optee/optee_private.h | 1 +
drivers/tee/optee/smc_abi.c | 5 ++++-
drivers/tee/optee/supp.c | 8 ++++++++
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/tee/optee/optee_private.h b/drivers/tee/optee/optee_private.h
index 46f74ab07c7e..83380974ff44 100644
--- a/drivers/tee/optee/optee_private.h
+++ b/drivers/tee/optee/optee_private.h
@@ -164,6 +164,7 @@ struct optee {
bool scan_bus_done;
struct workqueue_struct *scan_bus_wq;
struct work_struct scan_bus_work;
+ bool shutting_down;
};
struct optee_session {
diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c
index 449d6a72d289..10af747da816 100644
--- a/drivers/tee/optee/smc_abi.c
+++ b/drivers/tee/optee/smc_abi.c
@@ -1356,7 +1356,10 @@ static int optee_smc_remove(struct platform_device *pdev)
*/
static void optee_shutdown(struct platform_device *pdev)
{
- optee_disable_shm_cache(platform_get_drvdata(pdev));
+ struct optee *optee = platform_get_drvdata(pdev);
+
+ optee->shutting_down = true;
+ optee_disable_shm_cache(optee);
}
static int optee_probe(struct platform_device *pdev)
diff --git a/drivers/tee/optee/supp.c b/drivers/tee/optee/supp.c
index 322a543b8c27..801b4ec659e8 100644
--- a/drivers/tee/optee/supp.c
+++ b/drivers/tee/optee/supp.c
@@ -83,6 +83,14 @@ u32 optee_supp_thrd_req(struct tee_context *ctx, u32 func, size_t num_params,
bool interruptable;
u32 ret;
+ /*
+ * When the system is shutting down we cannot talk
+ * to the supplicant anymore even if we seem to have
+ * an open session to it.
+ */
+ if (optee->shutting_down)
+ return TEEC_ERROR_COMMUNICATION;
+
/*
* Return in case there is no supplicant available and
* non-blocking request.
--
2.30.2
Signed-off-by: Wang Cheng <wanngchenng(a)gmail.com>
---
Documentation/staging/tee.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/staging/tee.rst b/Documentation/staging/tee.rst
index 3c63d8dcd61e..498343c7ab08 100644
--- a/Documentation/staging/tee.rst
+++ b/Documentation/staging/tee.rst
@@ -255,7 +255,7 @@ The following picture shows a high level overview of AMD-TEE::
+--------------------------+ +---------+--------------------+
At the lowest level (in x86), the AMD Secure Processor (ASP) driver uses the
-CPU to PSP mailbox regsister to submit commands to the PSP. The format of the
+CPU to PSP mailbox register to submit commands to the PSP. The format of the
command buffer is opaque to the ASP driver. It's role is to submit commands to
the secure processor and return results to AMD-TEE driver. The interface
between AMD-TEE driver and AMD Secure Processor driver can be found in [6].
@@ -290,7 +290,7 @@ cancel_req driver callback is not supported by AMD-TEE.
The GlobalPlatform TEE Client API [5] can be used by the user space (client) to
talk to AMD's TEE. AMD's TEE provides a secure environment for loading, opening
-a session, invoking commands and clossing session with TA.
+a session, invoking commands and closing session with TA.
References
==========
--
2.33.1
Hello, I got problems here:
I built the whole system with yotcto 3.3.3, linux kernel 5.10, optee-os
3.14, platform for rk3399 ( was working for qemu platform ).
Console Configuration:
U-Boot / TrustFirmware-A / optee-os: all pointed console to uart2
linux dts: chosen and secure-chosen all pointed to uart2. uart2's status
and secure-status are both set to "okay"
Build Configuration:
optee-os:
DEBUG=1 \
CFG_TEE_CORE_LOG_LEVEL=4 \
CFG_TEE_CORE_DEBUG=y \
CFG_TEE_TA_LOG_LEVEL=4 \
...
both optee-examples and my TA:
DEBUG=1 \
CFG_TEE_TA_LOG_LEVEL=4 \
...
During boot I can see D/TC: logs, but no any D/TA: log is output.
Some D/TC log like this:
D/TC:? 0 tee_ta_init_session_with_context:607 Re-open TA xxxxx
D/TC:? 0 tee_ta_close_session:512 csess 0xDDDDDD id 1
D/TC:? 0 tee_ta_close_session:531 Destroy session
My TA has correct output, no crashes,or other errors
Thanks.
This V3 series covers points uncovered during the review of the previous
series, one major point being that register readout should not be used
for dynamic JR availability check due to its unreliability.
Instead, JR should have a proper status set in FDT which indicates the
availability of the ring in NS-World. This status is aligned with what
BootROM code configures, and can be modified by all actors in the boot
chain.
Therefore, patch in V2 series that was handling the dynamic JR
availability check is dropped in this series and replaced by the patch
which sets proper DT status for JR nodes.
Andrey Zhizhikin (2):
crypto: caam - convert to use capabilities
arm64: dts: imx8m: define proper status for caam jr
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 4 +
arch/arm64/boot/dts/freescale/imx8mn.dtsi | 4 +
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 4 +
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 4 +
drivers/crypto/caam/caamalg_qi.c | 2 +-
drivers/crypto/caam/ctrl.c | 115 ++++++++++++++--------
drivers/crypto/caam/intern.h | 20 ++--
drivers/crypto/caam/jr.c | 19 +++-
drivers/crypto/caam/regs.h | 2 -
9 files changed, 122 insertions(+), 52 deletions(-)
base-commit: 04fe99a8d936d46a310ca61b8b63dc270962bf01
--
2.25.1