As we are developing platforms to enable RPMB secure storage + fTPM TA, we realize that the current design of optee-os relying on a user space daemon tee-supplicant to serve requests cannot meet requirements of another open source linux kernel, IMA(Integrity Measurement Architecture). This module will try to collect data from TPM devices, which in our case, is fTPM TA. It has to collect data when kernel space is booting up, so we cannot delay these requests further until user space is up. With RPMB as our secure storage, some requests will be sent back to kernel space, but tee-supplicant context is not yet initialized, which results in IMA detection of TPM devices failed. Therefore, failed on the measurements we need.
I am wondering if we have related discussion on how modify the design to serve optee-os requests during kernel bootup. I can't find related topics in LKML archive.
Cat from /Documentation/ABI/testing/sysfs-bus-optee-devices
Date: May 2020
OP-TEE bus provides reference to registered drivers under this directory. The <uuid>
matches Trusted Application (TA) driver and corresponding TA in secure OS. Drivers
are free to create needed API under optee-ta-<uuid> directory.
fTPM TA: microsoft/MSRSec: Security and Privacy Research at Microsoft (github.com)<https://github.com/microsoft/MSRSec>
IMA enabling: https://sourceforge.net/p/linux-ima/wiki/Home/#enabling-ima-measurement:~:t…
(in context of testing BTI support when OP-TEE is loaded as a secure partition on top of SEL2/Hafnium)
I read through the OP-TEE documentation, and would like to confirm:
CFG_CORE_BTI=y seems mandatorily required to support BTI in TAs. It means we cannot enable independently BTI for TAs and 'disable' for TEE core, is this correct?
Interestingly I noticed I can build with CFG_CORE_BTI=n and CTG_TA_BTI=y but I appreciate the end result is that the TA get BTI landpads but is not effectively leveraging the arch extension because code page aren't guarde if TEE core option isn't enabled.
I was investigating a way to omit building a specific toolchain as it appears to be required when CFG_CORE_BTI=y, but I'll go ahead if there's no way round.
Out of curiosity is OP-TEE core pulling gcc libraries? And if yes, which kind? I naively thought OP-TEE core would be freestanding or be independent from toolchain libs.
Thanks & Regards,
Hello arm-soc maintainers,
Please pull these small fixes in the TEE subssytem. The OP-TEE driver
patch fixes an error which was introduced during the merge window. I'm
not sure if the error really can be triggered, but it would be nice to
have it fixed before the release.
The following changes since commit b13baccc3850ca8b8cccbf8ed9912dbaa0fdf7f3:
Linux 5.19-rc2 (2022-06-12 16:11:37 -0700)
are available in the Git repository at:
for you to fetch changes up to e5ce073c8a1e01b215a5eb32ba48f8d17ded3bd5:
tee: tee_get_drvdata(): fix description of return value (2022-07-08 10:51:24 +0200)
Fixes for TEE subsystem
A fix for the recently merged commit ed8faf6c8f8c ("optee: add
OPTEE_SMC_CALL_WITH_RPC_ARG and OPTEE_SMC_CALL_WITH_REGD_ARG").
Two small fixes in comment, repeated words etc.
Jiang Jian (1):
optee: Remove duplicate 'of' in two places.
Marc Kleine-Budde (1):
tee: tee_get_drvdata(): fix description of return value
Yang Yingliang (1):
optee: smc_abi.c: fix wrong pointer passed to IS_ERR/PTR_ERR()
drivers/tee/optee/optee_smc.h | 2 +-
drivers/tee/optee/smc_abi.c | 4 ++--
drivers/tee/tee_core.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
[BCC all OP-TEE maintainers]
Hi OP-TEE maintainers & contributors,
OP-TEE v3.17.0 is scheduled to be released on 2022-07-15. 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/5395
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: