On 10.04.26 10:36, Jan Kiszka wrote:
On 10.04.26 09:59, Jan Kiszka wrote:
On 10.04.26 07:45, Jan Kiszka wrote:
On 10.04.26 07:37, Jens Wiklander wrote:
Hi,
On Thu, Apr 9, 2026 at 7:41 PM Jan Kiszka via OP-TEE op-tee@lists.trustedfirmware.org wrote:
Hi all,
to avoid that I'm debugging further this error I get during boot with CONFIG_RPMB=y in the kernel and CFG_IN_TREE_EARLY_TAS=pkcs11/fd02c9da...:
[ 0.359372] mmcblk0boot0: mmc0:0001 QEMU!! 4.00 MiB [ 0.361779] mmcblk0boot1: mmc0:0001 QEMU!! 4.00 MiB [ 0.363761] mmcblk0rpmb: mmc0:0001 QEMU!! 2.00 MiB, chardev (248:0) D/TC:? 0 tee_ta_init_session_with_context:569 Re-open trusted service 7011a688-ddde-4053-a5a9-7b3c4ddf13b8 D/TC:? 0 legacy_rpmb_init:1143 Trying legacy RPMB init
The in-kernel routing didn't initialize as expected, so OP-TEE is falling back to the tee-supplicant based RPMB communication.
E/TC:? 0 get_rpc_alloc_res:646 RPC allocation failed. Non-secure world result: ret=0xffff000c ret_origin=0x2 D/TC:? 0 tee_ta_invoke_command:830 Error: f0100003 of 4 D/TC:? 0 tee_ta_close_session:469 csess 0xc0210910 id 1 D/TC:? 0 tee_ta_close_session:488 Destroy session
Is it possible at all to run the PKCS#11 TA without userland tee- supplicant? I thought it only needs the supplicant for RPMB, thus should be fine with the in-kernel routing (which is active), but maybe that is not true.
Yes, I think so. I haven't tried it myself, though. Anyway, the log tells that OP-TEE isn't using in-kernel routing. You can also check /sys/class/tee/teepriv0/rpmb_routing_model to see what the driver has negotiated.
# cat /sys/class/tee/teepriv0/rpmb_routing_model kernel
And if I build optee as module and load it later, then call "pkcs1-tool --module /usr/lib/libckteec.so.0 -I", it also waits for userspace tee here:
... F/TC:? 0 trace_syscall:147 syscall #8 (syscall_check_access_rights) F/TC:? 0 trace_syscall:147 syscall #41 (syscall_storage_obj_open) D/TC:? 0 legacy_rpmb_init:1143 Trying legacy RPMB init I/TC: thread_rpc_alloc 0, arg->ret ffff0000 I/TC: get_rpc_alloc_res: bt 0 size 8192
I instrumented further, and I'm getting an OPTEE_RPC_CMD_SHM_ALLOC with OPTEE_RPC_SHM_TYPE_APPL, not OPTEE_RPC_SHM_TYPE_KERNEL - this is where things are failing or blocking.
I think I'm getting closer: We have key-writing enabled for the QEMU target (key is not persisted there yet), and that seems to enforce legacy init all the time:
https://github.com/OP-TEE/optee_os/blob/15bbaa331fb6d69466c4880a1af1e8e9580c...
If I got it right, legacy_rpmb_init requires a userspace supplicant, doesn't it?
Things start to make sense: The QEMU image we assemble in isar-cip-core [1] does the first RPMB access and the key writing already via U-Boot, and U-Boot's supplicant does not differentiate between the two RPC_SHM_TYPEs - how should it? So, RPMB initialization is already done when the kernel later on loads its optee driver and starts to communicate.
In the setup above, though, we do not have a U-Boot, we directly boot from TF-A into the Linux. And that seems to send us into the error / blocking on tee-supplicant from userspace.
Can / should this be changed?
Jan
[1] https://gitlab.com/cip-project/cip-core/isar-cip-core