Re: PKCS#11 TA needs userland supplicant?

On 10.04.26 15:01, Jens Wiklander wrote:
> Hi,
> 
> On Fri, Apr 10, 2026 at 11:27 AM Jan Kiszka <[email protected]> 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
>>>>>> <[email protected]> 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/15bbaa331fb6d69466c4880a1af1e8e9580c95f1/core/tee/tee_rpmb_fs.c#L1248
>>>
>>> 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

-- 
Siemens AG, Foundational Technologies
Linux Expert Center