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