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 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.
All is fine - minus that error message - if I later on start tee- supplicant and use the PKCS#11 TA then.
Thanks, Jan
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.
Cheers, Jens
All is fine - minus that error message - if I later on start tee- supplicant and use the PKCS#11 TA then.
Thanks, Jan
-- Siemens AG, Foundational Technologies Linux Expert Center
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
Jan
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.
Jan
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?
Jan
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
Hi,
On Fri, Apr 10, 2026 at 11:27 AM Jan Kiszka jan.kiszka@siemens.com wrote:
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?
Yes
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.
Yes, but I was expecting tee_rpmb_reinit() to be called from the Device PTA when the kernel has discovered the RPMB device. tee_rpmb_reinit() causes the RPMB driver in OP-TEE to restart probing and should switch from the legacy setup.
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.
Without a key programmed into RPMB?
Can / should this be changed?
It sounds like the problem could be RPMB key programming. I'm testing in-kernel RPMB routing where the key is already programmed for each release.
We want to move away from OP-TEE programming the RPMB key, so a more advanced combination with that seems the wrong direction.
Cheers, Jens
On 10.04.26 15:01, Jens Wiklander wrote:
Hi,
On Fri, Apr 10, 2026 at 11:27 AM Jan Kiszka jan.kiszka@siemens.com wrote:
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?
Yes
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.
Yes, but I was expecting tee_rpmb_reinit() to be called from the Device PTA when the kernel has discovered the RPMB device. tee_rpmb_reinit() causes the RPMB driver in OP-TEE to restart probing and should switch from the legacy setup.
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.
Without a key programmed into RPMB?
It's QEMU in both cases: We start without a key on every boot. So we compile optee for those cases with key-writing enabled.
Can / should this be changed?
It sounds like the problem could be RPMB key programming. I'm testing in-kernel RPMB routing where the key is already programmed for each release.
We want to move away from OP-TEE programming the RPMB key, so a more advanced combination with that seems the wrong direction.
Well, plan B is implementing full state persistence for QEMU RPMB, including the key. Something I was pushing to the backlog as "nice to have but not needed for current tests".
Jan
op-tee@lists.trustedfirmware.org
-
Jan Kiszka -
Jens Wiklander