The recent patch  for the OP-TEE Dispatcher in TF-A proposes a way
of post-boot loading OP-TEE by the Linux kernel with signature
verification in the normal world only. This has previously been
discussed in this mail thread  about half a year ago. Ultimately,
it was concluded that this should in principle be accepted upstream as
a platform choice to allow this or not. There are concerns that what
we have in upstream TF-A should serve as good examples, and trusting
the normal world to verify secure world software might not meet that
criterion. There are also concerns about adding signature verification
Leaving the secure world wide open until the Linux kernel has been
able to successfully load and verify an OP-TEE binary seems very
risky. Even if it's claimed that the normal world can be trusted at
this point, we're still giving up a critical level of defense without
a good reason.
I've started to review , but it should not be accepted for merging
without support and approval from other maintainers.
I would like to explore other options in this mail thread. In  it
was suggested that a remnant of bl2 could be kept to verify OP-TEE
before starting to execute it. This could be taken one step further
and load a limited OP-TEE at boot which later is updated live, almost
like what's discussed in . This should minimize the impact on TF-A
and also leave OP-TEE in charge of accepting an update instead of a
divided responsibility between the normal world and TF-A.
This RFC series introduces the op-tee based EFI Runtime Variable
The eMMC device is typically owned by the non-secure world(linux in
this case). There is an existing solution utilizing eMMC RPMB partition
for EFI Variables, it is implemented by interacting with
OP-TEE, StandaloneMM(as EFI Variable Service Pseudo TA), eMMC driver
and tee-supplicant. The last piece is the tee-based variable access
driver to interact with OP-TEE and StandaloneMM.
Masahisa Kojima (2):
efi: expose efivar generic ops register function
tee: Add op-tee helper functions for variable access
drivers/firmware/efi/efi.c | 12 +
drivers/tee/optee/Kconfig | 10 +
drivers/tee/optee/Makefile | 1 +
drivers/tee/optee/mm_communication.h | 249 +++++++++++
drivers/tee/optee/optee_private.h | 5 +-
drivers/tee/optee/optee_stmm_efi.c | 598 +++++++++++++++++++++++++++
drivers/tee/tee_core.c | 23 ++
include/linux/efi.h | 4 +
include/linux/tee_drv.h | 23 ++
9 files changed, 924 insertions(+), 1 deletion(-)
create mode 100644 drivers/tee/optee/mm_communication.h
create mode 100644 drivers/tee/optee/optee_stmm_efi.c
Add a new ioctl called TEE_IOC_SHM_REGISTER_FD to register a
shared memory from a dmabuf file descriptor.
This new ioctl will allow the Linux Kernel to register a buffer
to be used by the Secure Data Path OPTEE OS feature.
Please find more information here:
Patch tested on Hikey 6220.
Etienne Carriere (1):
tee: new ioctl to a register tee_shm from a dmabuf file descriptor
drivers/tee/tee_core.c | 38 +++++++++++++++
drivers/tee/tee_shm.c | 99 +++++++++++++++++++++++++++++++++++++++-
include/linux/tee_drv.h | 11 +++++
include/uapi/linux/tee.h | 29 ++++++++++++
4 files changed, 175 insertions(+), 2 deletions(-)
It's soon time for another LOC monthly meeting. For time and connection
details see the calendar at https://www.trustedfirmware.org/meetings/
I have one topic to discuss:
OP-TEE 3.20.0 is just released and a PR  to upgrade from TEE Internal
Core API version 1.1 to 1.3.1 is soon to be merged. This may bump the
major OP-TEE version in the next release. There's in particular the
define TEE_ALG_SM2_PKE which is tricky to keep compatible when
upgrading. We have some time until the next release to determine if this
is reason enough to bump the major version.
Any other topics?
This small series aggregates 2 change proposals related to OP-TEE async notif.
I've made a single series since the 2 patches hit the same portions of optee
driver source file and I think this will help the review. If you prefer having
independent post and deal with the conflicts afterward, please tell me.
Patch "optee: add per cpu asynchronous notification" aims at allowing optee
to use a per-cpu interrupt (PPI on Arm CPUs) for async notif instead of a
shared peripheral interrupt.
The 2 next patches implement a new feature in OP-TEE, based on optee async
notif. The allow optee driver to behave as an interrupt controller, for
when a secure OP-TEE event is to be delivered to the Linux kernel as a
Etienne Carriere (3):
optee: add per cpu asynchronous notification
dt-bindings: arm: optee: add interrupt controller properties
optee core: add irq chip using optee async notification
.../arm/firmware/linaro,optee-tz.yaml | 19 +-
drivers/tee/optee/optee_private.h | 24 ++
drivers/tee/optee/optee_smc.h | 78 +++++-
drivers/tee/optee/smc_abi.c | 249 +++++++++++++++++-
4 files changed, 358 insertions(+), 12 deletions(-)
[BCC all OP-TEE maintainers]
Hi OP-TEE maintainers & contributors,
OP-TEE v3.20.0 is scheduled to be released on 2023-01-20. 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/5751
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
I have a few questions about the optee device tree and tee driver.
In our environment, optee uses version 3.19 vexpress-fvp and runs on top of hafnium as SPMC. Here's my question.
1. Does the current optee version support adding ACPI table iterm for optee to enable REE to identify the installed optee driver so that TA and CA can establish communication?
(I raise this question because I cannot find the corresponding optee node in "/sys/devices/platform" in the current linux environment.
While in the QEMU runtime environment, the corresponding optee node is in "/proc/device-tree/firmware", i.e. "linaro,optee-tz".)
2. If I want to transfer dtb file which includes a device tree node written by optee to linux, How to configure CFG_DT, CFG_DT_ADDR, and CFG_EXTERNAL_DTB_OVERLAY?
(I understand that this method should be independent from the method in question 1. If it is not, look forward your explain.)
Looking forward to your reply. Thanks.