Hi all,
This adds supports for the OP-TEE driver to communicate with secure world
using FF-A [1] as transport.
These patches are based on the FF-A v7 patch set by Sudeep Holla [2] [3].
There is one change to the TEE subsystem with "tee: add sec_world_id to
struct tee_shm" to add support for holding globally unique handle assigned
by the FF-A. This is a field that I believe could useful for the AMDTEE
driver too.
For communication the OP-TEE message protocol is still used, but with a new
type of memory reference, struct optee_msg_param_fmem, to carry the
information needed by FF-A. The OP-TEE driver is refactored internally with
to sets of callbacks, one for the old SMC based communication and another
set with FF-A as transport.
There is also a difference in how the drivers are instantiated. With the
SMC based transport we have a platform driver, module_platform_driver(),
today which we're keeping as is for this configuration. In a FF-A system we
have a FF-A driver, module_ffa_driver(), instead.
The OP-TEE driver can be compiled for both targets at the same time and
it's up to runtime configuration (device tree or ACPI) to decide how it's
initialized.
Thanks,
Jens
[1] https://developer.arm.com/documentation/den0077/latest
[2] https://lore.kernel.org/linux-arm-kernel/20210521151033.181846-1-sudeep.hol…
[3] git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git v5.13/ffa
v1->v2:
- Rebased to the FF-A v7 patch
- Fixed a couple of reports from kernel test robot <lkp(a)intel.com>
Jens Wiklander (5):
tee: add sec_world_id to struct tee_shm
optee: simplify optee_release()
optee: refactor driver with internal callbacks
optee: add a FF-A memory pool
optee: add FF-A support
drivers/tee/optee/call.c | 325 +++++++++++---
drivers/tee/optee/core.c | 689 ++++++++++++++++++++++++++----
drivers/tee/optee/optee_ffa.h | 153 +++++++
drivers/tee/optee/optee_msg.h | 27 +-
drivers/tee/optee/optee_private.h | 88 +++-
drivers/tee/optee/rpc.c | 137 +++++-
drivers/tee/optee/shm_pool.c | 65 ++-
drivers/tee/optee/shm_pool.h | 1 +
include/linux/tee_drv.h | 7 +-
9 files changed, 1326 insertions(+), 166 deletions(-)
create mode 100644 drivers/tee/optee/optee_ffa.h
--
2.25.1
When the system is going to hibernate or suspend it might happen
that the tee-supplicant task is frozen first.
In this case a running OP-TEE task might get stuck in the loop using
wait_for_completion_interruptible to wait for response of tee-supplicant.
As a consequence other OP-TEE tasks waiting for the above or a
succeeding stuck OP-TEE task might get stuck as well
- waiting for call queue entry to be completed
- waiting for OPTEE_RPC_WAIT_QUEUE_WAKEUP
This will result in the tasks "refusing to freeze" and
the hibernate or suspend will fail.
OP-TEE issue: https://github.com/OP-TEE/optee_os/issues/4581
- Read back the object
PM: suspend entry (s2idle)
Filesystems sync: 0.000 seconds
Freezing user space processes ...
Freezing of tasks failed after 20.008 seconds (3 tasks refusing to freeze, wq_busy=0):
task:optee_example_s state:R running task stack: 0 pid: 124 ppid: 1 flags:0x00000001
[<807d3e24>] (__schedule) from [<841c4000>] (0x841c4000)
task:optee_example_s state:D stack: 0 pid: 126 ppid: 1 flags:0x00000001
[<807d3e24>] (__schedule) from [<807d41d0>] (schedule+0x60/0x120)
[<807d41d0>] (schedule) from [<807d7ffc>] (schedule_timeout+0x1f4/0x340)
[<807d7ffc>] (schedule_timeout) from [<807d56a0>] (wait_for_completion+0x94/0xfc)
[<807d56a0>] (wait_for_completion) from [<80692134>] (optee_cq_wait_for_completion+0x14/0x60)
[<80692134>] (optee_cq_wait_for_completion) from [<806924dc>] (optee_do_call_with_arg+0x14c/0x154)
[<806924dc>] (optee_do_call_with_arg) from [<80692edc>] (optee_shm_unregister+0x78/0xcc)
[<80692edc>] (optee_shm_unregister) from [<80690a9c>] (tee_shm_release+0x88/0x174)
[<80690a9c>] (tee_shm_release) from [<8057f89c>] (dma_buf_release+0x44/0xb0)
[<8057f89c>] (dma_buf_release) from [<8028e4e8>] (__dentry_kill+0x110/0x17c)
[<8028e4e8>] (__dentry_kill) from [<80276cfc>] (__fput+0xc0/0x234)
[<80276cfc>] (__fput) from [<80140b1c>] (task_work_run+0x90/0xbc)
[<80140b1c>] (task_work_run) from [<8010b1c8>] (do_work_pending+0x4a0/0x5a0)
[<8010b1c8>] (do_work_pending) from [<801000cc>] (slow_work_pending+0xc/0x20)
Exception stack(0x843f5fb0 to 0x843f5ff8)
5fa0: 00000000 7ef63448 fffffffe 00000000
5fc0: 7ef63448 76f163b0 7ef63448 00000006 7ef63448 7ef634e0 7ef63438 00000000
5fe0: 00000006 7ef63400 76e74833 76dff856 800e0130 00000004
task:optee_example_s state:D stack: 0 pid: 128 ppid: 1 flags:0x00000001
[<807d3e24>] (__schedule) from [<807d41d0>] (schedule+0x60/0x120)
[<807d41d0>] (schedule) from [<807d7ffc>] (schedule_timeout+0x1f4/0x340)
[<807d7ffc>] (schedule_timeout) from [<807d56a0>] (wait_for_completion+0x94/0xfc)
[<807d56a0>] (wait_for_completion) from [<8069359c>] (optee_handle_rpc+0x554/0x710)
[<8069359c>] (optee_handle_rpc) from [<806924cc>] (optee_do_call_with_arg+0x13c/0x154)
[<806924cc>] (optee_do_call_with_arg) from [<80692910>] (optee_invoke_func+0x110/0x190)
[<80692910>] (optee_invoke_func) from [<8068fe3c>] (tee_ioctl+0x113c/0x1244)
[<8068fe3c>] (tee_ioctl) from [<802892ec>] (sys_ioctl+0xe0/0xa24)
[<802892ec>] (sys_ioctl) from [<80100060>] (ret_fast_syscall+0x0/0x54)
Exception stack(0x8424ffa8 to 0x8424fff0)
ffa0: 00000000 7eb67584 00000003 8010a403 7eb67438 7eb675fc
ffc0: 00000000 7eb67584 7eb67604 00000036 7eb67448 7eb674e0 7eb67438 00000000
ffe0: 76ef7030 7eb6742c 76ee6469 76e83178
OOM killer enabled.
Restarting tasks ... done.
PM: suspend exit
sh: write error: Device or resource busy
The patch set will switch to interruptible waits and add try_to_freeze to allow the waiting
OP-TEE tasks to be frozen as well.
---
In my humble understanding without these patches OP-TEE tasks have only been frozen in user-space.
With these patches it is possible that OP-TEE tasks are frozen although the OP-TEE command
invocation didn't complete.
I'm unable to judge if there are any OP-TEE implementations relying on the fact that suspend won't
happen while the OP-TEE command invocation didn't complete.
The theoretical alternative would be to prevent that tee-supplicant is frozen first.
I was able to reproduce the issue in OP-TEE QEMU v7 using a modified version of
optee_example_secure_storage (loop around REE FS read, support multi-session).
See https://github.com/OP-TEE/optee_os/issues/4581 for details.
After applying these patches (minor adjustments of the includes) I was no longer able to
reproduce the issues.
In my tests OP-TEE QEMU v7 did suspend and resume without troubles.
I'm not able to test on other devices supporting OP-TEE.
I decided to handle each of the locations the OP-TEE task could get stuck as a separate commit.
The downside is that the above call stack doesn't really fit to any of the commits.
Christoph Gellner (3):
tee: optee: Allow to freeze the task waiting for tee-supplicant
tee: optee: Allow to freeze while waiting for call_queue
tee: optee: Allow to freeze while waiting in
OPTEE_RPC_WAIT_QUEUE_SLEEP
drivers/tee/optee/call.c | 8 +++++++-
drivers/tee/optee/rpc.c | 9 ++++++++-
drivers/tee/optee/supp.c | 3 +++
3 files changed, 18 insertions(+), 2 deletions(-)
base-commit: c4681547bcce777daf576925a966ffa824edd09d
--
2.32.0.rc0
Hi,
LOC monthly meeting is planned to take place Thursday May 27(a)17.00 (UTC+2).
Looking for topics from people. If you have anything you'd like to discuss,
please let me know.
I have a couple of examples of things that could be worth having a chat
about if there are no other proposals.
- OP-TEE and MISRA C
- Rust in OP-TEE
- SDP (ION support removed in Linux kernel will affect OP-TEE's SDP
solution)
Meeting details:
---------------
Date/time: Thursday May 27(a)17.00 (UTC+2)
https://everytimezone.com/s/83944ce6
Connection details: https://www.trustedfirmware.org/meetings/
Meeting notes: http://bit.ly/loc-notes
Project page: https://www.linaro.org/projects/#LOC
Regards,
Joakim on behalf of the Linaro OP-TEE team
Hello arm-soc maintainers,
Please pull this small OP-TEE driver fix which uses export_uuid() to copy
the client UUID instead of making asumptions about the internal format of
uuid_t.
Thanks,
Jens
The following changes since commit 6efb943b8616ec53a5e444193dccf1af9ad627b5:
Linux 5.13-rc1 (2021-05-09 14:17:44 -0700)
are available in the Git repository at:
git://git.linaro.org/people/jens.wiklander/linux-tee.git tags/optee-fix-for-v5.13
for you to fetch changes up to 673c7aa2436bfc857b92417f3e590a297c586dde:
optee: use export_uuid() to copy client UUID (2021-05-18 07:59:27 +0200)
----------------------------------------------------------------
OP-TEE use export_uuid() to copy UUID
----------------------------------------------------------------
Jens Wiklander (1):
optee: use export_uuid() to copy client UUID
drivers/tee/optee/call.c | 6 ++++--
drivers/tee/optee/optee_msg.h | 6 ++++--
2 files changed, 8 insertions(+), 4 deletions(-)
From: Allen Pais <apais(a)linux.microsoft.com>
The following out of memory errors are seen on kexec reboot
from the optee core.
[ 0.368428] tee_bnxt_fw optee-clnt0: tee_shm_alloc failed
[ 0.368461] tee_bnxt_fw: probe of optee-clnt0 failed with error -22
tee_shm_release() is not invoked on dma shm buffer.
Implement .shutdown() in optee core as well as bnxt firmware driver
to handle the release of the buffers correctly.
More info:
https://github.com/OP-TEE/optee_os/issues/3637
v2:
keep the .shutdown() method simple. [Jens Wiklander]
Allen Pais (2):
optee: fix tee out of memory failure seen during kexec reboot
firmware: tee_bnxt: implement shutdown method to handle kexec reboots
drivers/firmware/broadcom/tee_bnxt_fw.c | 9 +++++++++
drivers/tee/optee/core.c | 20 ++++++++++++++++++++
2 files changed, 29 insertions(+)
--
2.25.1
Hello arm-soc maintainers,
Please pull this AMDTEE driver fix which adds reference counting to
loaded TAs which is needed for proper life cycle management of TAs.
Note that this isn't a usual Arm driver update. This targets AMD instead,
but is part of the TEE subsystem.
Thanks,
Jens
The following changes since commit 9f4ad9e425a1d3b6a34617b8ea226d56a119a717:
Linux 5.12 (2021-04-25 13:49:08 -0700)
are available in the Git repository at:
git://git.linaro.org/people/jens.wiklander/linux-tee.git tags/amdtee-fixes-for-v5.13
for you to fetch changes up to 9f015b3765bf593b3ed5d3b588e409dc0ffa9f85:
tee: amdtee: unload TA only when its refcount becomes 0 (2021-05-05 13:00:11 +0200)
----------------------------------------------------------------
AMD-TEE reference count loaded TAs
----------------------------------------------------------------
Rijo Thomas (1):
tee: amdtee: unload TA only when its refcount becomes 0
drivers/tee/amdtee/amdtee_private.h | 13 +++++
drivers/tee/amdtee/call.c | 94 +++++++++++++++++++++++++++++++++----
drivers/tee/amdtee/core.c | 15 +++---
3 files changed, 106 insertions(+), 16 deletions(-)
From: Jerome Forissier <jerome(a)forissier.org>
[ Upstream commit c650b8dc7a7910eb25af0aac1720f778b29e679d ]
When Secure World returns, it may have changed the size attribute of the
memory references passed as [in/out] parameters. The GlobalPlatform TEE
Internal Core API specification does not restrict the values that this
size can take. In particular, Secure World may increase the value to be
larger than the size of the input buffer to indicate that it needs more.
Therefore, the size check in optee_from_msg_param() is incorrect and
needs to be removed. This fixes a number of failed test cases in the
GlobalPlatform TEE Initial Configuratiom Test Suite v2_0_0_0-2017_06_09
when OP-TEE is compiled without dynamic shared memory support
(CFG_CORE_DYN_SHM=n).
Reviewed-by: Sumit Garg <sumit.garg(a)linaro.org>
Suggested-by: Jens Wiklander <jens.wiklander(a)linaro.org>
Signed-off-by: Jerome Forissier <jerome(a)forissier.org>
Signed-off-by: Jens Wiklander <jens.wiklander(a)linaro.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
drivers/tee/optee/core.c | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
index 834884c370c5..63187b07dde0 100644
--- a/drivers/tee/optee/core.c
+++ b/drivers/tee/optee/core.c
@@ -86,16 +86,6 @@ int optee_from_msg_param(struct tee_param *params, size_t num_params,
return rc;
p->u.memref.shm_offs = mp->u.tmem.buf_ptr - pa;
p->u.memref.shm = shm;
-
- /* Check that the memref is covered by the shm object */
- if (p->u.memref.size) {
- size_t o = p->u.memref.shm_offs +
- p->u.memref.size - 1;
-
- rc = tee_shm_get_pa(shm, o, NULL);
- if (rc)
- return rc;
- }
break;
default:
return -EINVAL;
--
2.30.2
From: Jerome Forissier <jerome(a)forissier.org>
[ Upstream commit c650b8dc7a7910eb25af0aac1720f778b29e679d ]
When Secure World returns, it may have changed the size attribute of the
memory references passed as [in/out] parameters. The GlobalPlatform TEE
Internal Core API specification does not restrict the values that this
size can take. In particular, Secure World may increase the value to be
larger than the size of the input buffer to indicate that it needs more.
Therefore, the size check in optee_from_msg_param() is incorrect and
needs to be removed. This fixes a number of failed test cases in the
GlobalPlatform TEE Initial Configuratiom Test Suite v2_0_0_0-2017_06_09
when OP-TEE is compiled without dynamic shared memory support
(CFG_CORE_DYN_SHM=n).
Reviewed-by: Sumit Garg <sumit.garg(a)linaro.org>
Suggested-by: Jens Wiklander <jens.wiklander(a)linaro.org>
Signed-off-by: Jerome Forissier <jerome(a)forissier.org>
Signed-off-by: Jens Wiklander <jens.wiklander(a)linaro.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
drivers/tee/optee/core.c | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
index 2f254f957b0a..1d71fcb13dba 100644
--- a/drivers/tee/optee/core.c
+++ b/drivers/tee/optee/core.c
@@ -87,16 +87,6 @@ int optee_from_msg_param(struct tee_param *params, size_t num_params,
return rc;
p->u.memref.shm_offs = mp->u.tmem.buf_ptr - pa;
p->u.memref.shm = shm;
-
- /* Check that the memref is covered by the shm object */
- if (p->u.memref.size) {
- size_t o = p->u.memref.shm_offs +
- p->u.memref.size - 1;
-
- rc = tee_shm_get_pa(shm, o, NULL);
- if (rc)
- return rc;
- }
break;
case OPTEE_MSG_ATTR_TYPE_RMEM_INPUT:
case OPTEE_MSG_ATTR_TYPE_RMEM_OUTPUT:
--
2.30.2