Fix kernel-doc warnings so that there no other kernel-doc issues
in <uapi/linux/tee.h>:
- add ending ':' to some struct members as needed for kernel-doc
- change struct name in kernel-doc to match the actual struct name (2x)
- add a @params: kernel-doc entry multiple times
Warning: tee.h:265 struct member 'ret_origin' not described
in 'tee_ioctl_open_session_arg'
Warning: tee.h:265 struct member 'num_params' not described
in 'tee_ioctl_open_session_arg'
Warning: tee.h:265 struct member 'params' not described
in 'tee_ioctl_open_session_arg'
Warning: tee.h:351 struct member 'num_params' not described
in 'tee_iocl_supp_recv_arg'
Warning: tee.h:351 struct member 'params' not described
in 'tee_iocl_supp_recv_arg'
Warning: tee.h:372 struct member 'num_params' not described
in 'tee_iocl_supp_send_arg'
Warning: tee.h:372 struct member 'params' not described
in 'tee_iocl_supp_send_arg'
Warning: tee.h:298: expecting prototype for struct
tee_ioctl_invoke_func_arg. Prototype was for
struct tee_ioctl_invoke_arg instead
Warning: tee.h:473: expecting prototype for struct
tee_ioctl_invoke_func_arg. Prototype was for struct
tee_ioctl_object_invoke_arg instead
Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org>
---
Cc: Jens Wiklander <jens.wiklander(a)linaro.org>
Cc: Sumit Garg <sumit.garg(a)kernel.org>
Cc: op-tee(a)lists.trustedfirmware.org
---
include/uapi/linux/tee.h | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
--- linux-next-20251022.orig/include/uapi/linux/tee.h
+++ linux-next-20251022/include/uapi/linux/tee.h
@@ -249,8 +249,9 @@ struct tee_ioctl_param {
* @cancel_id: [in] Cancellation id, a unique value to identify this request
* @session: [out] Session id
* @ret: [out] return value
- * @ret_origin [out] origin of the return value
- * @num_params [in] number of parameters following this struct
+ * @ret_origin: [out] origin of the return value
+ * @num_params: [in] number of &struct tee_ioctl_param entries in @params
+ * @params: array of ioctl parameters
*/
struct tee_ioctl_open_session_arg {
__u8 uuid[TEE_IOCTL_UUID_LEN];
@@ -276,14 +277,14 @@ struct tee_ioctl_open_session_arg {
struct tee_ioctl_buf_data)
/**
- * struct tee_ioctl_invoke_func_arg - Invokes a function in a Trusted
- * Application
+ * struct tee_ioctl_invoke_arg - Invokes a function in a Trusted Application
* @func: [in] Trusted Application function, specific to the TA
* @session: [in] Session id
* @cancel_id: [in] Cancellation id, a unique value to identify this request
* @ret: [out] return value
- * @ret_origin [out] origin of the return value
- * @num_params [in] number of parameters following this struct
+ * @ret_origin: [out] origin of the return value
+ * @num_params: [in] number of parameters following this struct
+ * @params: array of ioctl parameters
*/
struct tee_ioctl_invoke_arg {
__u32 func;
@@ -338,7 +339,8 @@ struct tee_ioctl_close_session_arg {
/**
* struct tee_iocl_supp_recv_arg - Receive a request for a supplicant function
* @func: [in] supplicant function
- * @num_params [in/out] number of parameters following this struct
+ * @num_params: [in/out] number of &struct tee_ioctl_param entries in @params
+ * @params: array of ioctl parameters
*
* @num_params is the number of params that tee-supplicant has room to
* receive when input, @num_params is the number of actual params
@@ -363,7 +365,8 @@ struct tee_iocl_supp_recv_arg {
/**
* struct tee_iocl_supp_send_arg - Send a response to a received request
* @ret: [out] return value
- * @num_params [in] number of parameters following this struct
+ * @num_params: [in] number of &struct tee_ioctl_param entries in @params
+ * @params: array of ioctl parameters
*/
struct tee_iocl_supp_send_arg {
__u32 ret;
@@ -454,11 +457,13 @@ struct tee_ioctl_shm_register_fd_data {
*/
/**
- * struct tee_ioctl_invoke_func_arg - Invokes an object in a Trusted Application
+ * struct tee_ioctl_object_invoke_arg - Invokes an object in a
+ * Trusted Application
* @id: [in] Object id
* @op: [in] Object operation, specific to the object
* @ret: [out] return value
* @num_params: [in] number of parameters following this struct
+ * @params: array of ioctl parameters
*/
struct tee_ioctl_object_invoke_arg {
__u64 id;
From: Jan Kiszka <jan.kiszka(a)siemens.com>
As seen with optee_ftpm, which uses ms-tpm-20-ref [1], a TPM may write
the current time epoch to its NV storage every 4 seconds if there are
commands sent to it. The 60 seconds periodic update of the entropy pool
that the hwrng kthread does triggers this, causing about 4 writes per
requests. Makes 2 millions per year for a 24/7 device, and that is a lot
for its backing NV storage.
It is therefore better to make the user intentionally enable this,
providing a chance to read the warning.
[1] https://github.com/Microsoft/ms-tpm-20-ref
Signed-off-by: Jan Kiszka <jan.kiszka(a)siemens.com>
---
drivers/char/tpm/Kconfig | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
index 8a8f692b6088..d64c929cacbe 100644
--- a/drivers/char/tpm/Kconfig
+++ b/drivers/char/tpm/Kconfig
@@ -45,13 +45,17 @@ config TCG_TPM2_HMAC
config HW_RANDOM_TPM
bool "TPM HW Random Number Generator support"
depends on TCG_TPM && HW_RANDOM && !(TCG_TPM=y && HW_RANDOM=m)
- default y
help
This setting exposes the TPM's Random Number Generator as a hwrng
device. This allows the kernel to collect randomness from the TPM at
boot, and provides the TPM randomines in /dev/hwrng.
- If unsure, say Y.
+ WARNING: Specifically firmware-based TPMs, possibly also hardware
+ variants, can wear-out from the frequent requests issued by the
+ Hardware Random Number Generator Core when filling the kernel's
+ entropy pool. These requests are sent once every minute by default,
+ and the TPM may write the current time to its NV storage for each of
+ them.
config TCG_TIS_CORE
tristate
--
2.51.0
Hi,
Tomorrow, Tuesday, it's time for another LOC monthly meeting. For time
and connection details, see the calendar at
https://www.trustedfirmware.org/meetings/
- OP-TEE version 4.8.0 has been released
- We have an op-tee channel at the Trusted Firmware Discord server
[1]. Last week, there was a message about improving the order of all
the config options we have in OP-TEE, the CFG_* variables. In the long
term, we might still aim for Kconfig, but that's quite a large step.
However, there are intermediate steps that we can take. I hope we'll
see more of this.
Are there any other topics?
[1] https://www.trustedfirmware.org/faq/
Cheers,
Jens
FYI: QEMU model is working fine, upstreaming started, feedback welcome.
Jan
On 24.08.25 09:18, Jan Kiszka wrote:
> This closes an old gap in system integration testing for the very
> complex ARM firmware stacks by adding fairly advanced Replay Protected
> Memory Block (RPMB) emulation to the eMMC device model. Key programming
> and message authentication are working, so is the write counter. Known
> users are happy with the result. What is missing, but not only for RPMB-
> related registers, is state persistence across QEMU restarts. This is OK
> at this stage for most test scenarios, though, and could still be added
> later on.
>
> What can already be done with it is demonstrated in the WIP branch of
> isar-cip-core at [1]: TF-A + OP-TEE + StandaloneMM TA + fTPM TA, used by
> U-Boot and Linux for UEFI variable storage and TPM scenarios. If you
> want to try: build qemu-arm64 target for trixie with 6.12-cip *head*
> kernel, enable secure boot and disk encryption, then run
>
> $ QEMU_PATH=/path/to/qemu-build/ ./start-qemu.sh
>
> Deploy snakeoil keys into PK, KEK and db after first boot to enable
> secure booting:
>
> root@demo:~# cert-to-efi-sig-list PkKek-1-snakeoil.pem PK.esl
> root@demo:~# sign-efi-sig-list -k PkKek-1-snakeoil.key -c PkKek-1-snakeoil.pem PK PK.esl PK.auth
> root@demo:~# efi-updatevar -f PK.auth db
> root@demo:~# efi-updatevar -f PK.auth KEK
> root@demo:~# efi-updatevar -f PK.auth PK
>
> Note that emulation is a bit slow in general, and specifically the
> partition encryption on first boot is taking 20 min. - we should
> probably reduce its size or understand if there is still something to
> optimize.
>
> Jan
>
> [1] https://gitlab.com/cip-project/cip-core/isar-cip-core/-/commits/wip/qemu-rp…
>
> Cc: "Daniel P. Berrangé" <berrange(a)redhat.com>
>
> Jan Kiszka (8):
> hw/sd/sdcard: Fix size check for backing block image
> hw/sd/sdcard: Add validation for boot-partition-size
> hw/sd/sdcard: Allow user-instantiated eMMC
> hw/sd/sdcard: Refactor sd_bootpart_offset
> hw/sd/sdcard: Add basic support for RPMB partition
> crypto/hmac: Allow to build hmac over multiple
> qcrypto_gnutls_hmac_bytes[v] calls
> hw/sd/sdcard: Handle RPMB MAC field
> scripts: Add helper script to generate eMMC block device images
>
> crypto/hmac-gcrypt.c | 4 +-
> crypto/hmac-glib.c | 4 +-
> crypto/hmac-gnutls.c | 4 +-
> crypto/hmac-nettle.c | 4 +-
> hw/sd/sd.c | 314 ++++++++++++++++++++++++++++++++++++++---
> hw/sd/sdmmc-internal.h | 24 +++-
> hw/sd/trace-events | 2 +
> include/crypto/hmac.h | 12 ++
> scripts/mkemmc.sh | 185 ++++++++++++++++++++++++
> 9 files changed, 530 insertions(+), 23 deletions(-)
> create mode 100755 scripts/mkemmc.sh
>
--
Siemens AG, Foundational Technologies
Linux Expert Center
[BCC all OP-TEE maintainers]
Hi OP-TEE maintainers & contributors,
OP-TEE version 4.8.0 is now scheduled to be released on 2025-10-24. 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/7567.
We will create the release candidate tag 4.8.0-rc1 this Friday,
allowing for a one-week testing period before the planned release.
You can find more information related to releases here:
https://optee.readthedocs.io/en/latest/general/releases.html
Thanks,
Jens
Main updates from version V18[2]:
- rework documentation for the release_fw ops
- rework function documentation in remoteproc_tee.c
- replace spinlock by mutex and generalize usage in remoteproc_tee.c
Main updates from version V17[1]:
- Fix: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h>
is missing
More details are available in each patch commit message.
[1] https://lore.kernel.org/linux-remoteproc/20250613091650.2337411-1-arnaud.po…
[2] https://lore.kernel.org/linux-remoteproc/20250616075530.4106090-1-arnaud.po…
Tested-on: commit 19272b37aa4f ("Linux 6.16-rc1")
Description of the feature:
--------------------------
This series proposes the implementation of a remoteproc tee driver to
communicate with a TEE trusted application responsible for authenticating
and loading the remoteproc firmware image in an Arm secure context.
1) Principle:
The remoteproc tee driver provides services to communicate with the OP-TEE
trusted application running on the Trusted Execution Context (TEE).
The trusted application in TEE manages the remote processor lifecycle:
- authenticating and loading firmware images,
- isolating and securing the remote processor memories,
- supporting multi-firmware (e.g., TF-M + Zephyr on a Cortex-M33),
- managing the start and stop of the firmware by the TEE.
2) Format of the signed image:
Refer to:
https://github.com/OP-TEE/optee_os/blob/master/ta/remoteproc/src/remoteproc…
3) OP-TEE trusted application API:
Refer to:
https://github.com/OP-TEE/optee_os/blob/master/ta/remoteproc/include/ta_rem…
4) OP-TEE signature script
Refer to:
https://github.com/OP-TEE/optee_os/blob/master/scripts/sign_rproc_fw.py
Example of usage:
sign_rproc_fw.py --in <fw1.elf> --in <fw2.elf> --out <signed_fw.sign> --key ${OP-TEE_PATH}/keys/default.pem
5) Impact on User space Application
No sysfs impact. The user only needs to provide the signed firmware image
instead of the ELF image.
For more information about the implementation, a presentation is available here
(note that the format of the signed image has evolved between the presentation
and the integration in OP-TEE).
https://resources.linaro.org/en/resource/6c5bGvZwUAjX56fvxthxds
Arnaud Pouliquen (6):
remoteproc: core: Introduce rproc_pa_to_va helper
remoteproc: Add TEE support
remoteproc: Introduce optional release_fw operation
dt-bindings: remoteproc: Add compatibility for TEE support
remoteproc: stm32: Create sub-functions to request shutdown and
release
remoteproc: stm32: Add support of an OP-TEE TA to load the firmware
.../bindings/remoteproc/st,stm32-rproc.yaml | 58 +-
drivers/remoteproc/Kconfig | 10 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/remoteproc_core.c | 52 ++
drivers/remoteproc/remoteproc_internal.h | 6 +
drivers/remoteproc/remoteproc_tee.c | 708 ++++++++++++++++++
drivers/remoteproc/stm32_rproc.c | 139 +++-
include/linux/remoteproc.h | 6 +
include/linux/remoteproc_tee.h | 87 +++
9 files changed, 1023 insertions(+), 44 deletions(-)
create mode 100644 drivers/remoteproc/remoteproc_tee.c
create mode 100644 include/linux/remoteproc_tee.h
base-commit: 19272b37aa4f83ca52bdf9c16d5d81bdd1354494
--
2.25.1