Re: optee-based efi runtime variable service on TI j784s4 platforms

Hi Ilias,

Thanks for your quick answer.

On Fri, Nov 8, 2024 at 4:48 PM Ilias Apalodimas
[off-list ref] wrote:

Hi Enric,

On Fri, 8 Nov 2024 at 12:26, Enric Balletbo i Serra [off-list ref] wrote:

quoted

Hi all,

I'm looking for any advice/clue to help me to progress on enabling
TEE-base EFI Runtime Variable Service on TI a j784s4 platforms.

I basically followed the steps described in u-boot documentation [1],
I enabled some debugging messages but I think I'm at the point that
the problem might be in the StandaloneMM application, and I'm not sure
how to debug it.

What I see is that when I run the tee-supplicant daemon, it looks like
the tee_client_open_session() call loops forever and the tee_stmm_efi
driver never ends to probe.

With debug enabled I got the following messages.

I assume reading and storing variables already works in U-Boot right?

Reading and storing variables to the RPMB partition in U-Boot works,
that's using the mmc rpmb command from u-boot, But setting
CONFIG_EFI_MM_COMM_TEE=y in u-boot I end with a similar behaviour
(although I'm not able to debug at u-boot level) What I see is that
u-boot gets stuck
when bootefi bootmgr is invoqued. I can also reproduce the issue with
bootefi hello.

=> run bootcmd
  Scanning for bootflows in all bootdevs
  Seq  Method       State   Uclass    Part  Name                      Filename
  ---  -----------  ------  --------  ----  ------------------------
----------------
  Scanning global bootmeth 'efi_mgr':
( gets stuck here)

or

=> bootefi hello
(gets stuck)

To debug I disabled CONFIG_EFI_MM_COMM_TEE to not get stuck and bypass
the error and go to Linux. My understanding is that
CONFIG_EFI_MM_COMM_TEE is only required to read/write efi variables at
u-boot level but OPTEE is running the StandaloneMM service. Am I
right?

quoted

# tee-supplicant
D/TC:? 0 tee_ta_init_session_with_context:557 Re-open trusted service
7011a688-ddde-4053-a5a9-7b3c4ddf13b8
D/TC:? 0 load_stmm:297 stmm load address 0x40004000
D/TC:? 0 spm_handle_scall:859 Received FFA version
D/TC:? 0 spm_handle_scall:867 Received FFA direct request
D/TC:? 0 spm_handle_scall:867 Received FFA direct request
D/TC:? 0 spm_handle_scall:867 Received FFA direct request
D/TC:? 0 spm_handle_scall:867 Received FFA direct request
D/TC:? 0 spm_handle_scall:867 Received FFA direct request
D/TC:? 0 spm_handle_scall:867 Received FFA direct request
D/TC:? 0 spm_handle_scall:867 Received FFA direct request
D/TC:? 0 spm_handle_scall:867 Received FFA direct request
D/TC:? 0 spm_handle_scall:867 Received FFA direct request
D/TC:? 0 spm_handle_scall:867 Received FFA direct request
D/TC:? 0 spm_handle_scall:867 Received FFA direct request
D/TC:? 0 spm_handle_scall:867 Received FFA direct request
D/TC:? 0 spm_handle_scall:867 Received FFA direct request
D/TC:? 0 spm_handle_scall:867 Received FFA direct request
D/TC:? 0 spm_handle_scall:867 Received FFA direct request
D/TC:? 0 spm_handle_scall:867 Received FFA direct request

And tracing the function calls gives me that:

      tee_stmm_efi_probe() {
             tee_client_open_context() {
               optee_get_version() {
                 tee_get_drvdata(); (ret=0xffff000002e55800)
               } (ret=0xd)
               tee_ctx_match(); (ret=0x1)
               optee_smc_open() {
                 tee_get_drvdata(); (ret=0xffff000002e55800)
                 optee_open() {
                   tee_get_drvdata(); (ret=0xffff000002e55800)
                 } (ret=0x0)
               } (ret=0x0)
             } (ret=0xffff000004e71c80)
             tee_client_open_session() {
               optee_open_session() {
                 tee_get_drvdata(); (ret=0xffff000002e55800)
                 optee_get_msg_arg() {
                   tee_get_drvdata(); (ret=0xffff000002e55800)
                   tee_shm_get_va(); (ret=0xffff000002909000)
                 } (ret=0xffff000002909000)
                 tee_session_calc_client_uuid(); (ret=0x0)
                 optee_to_msg_param(); (ret=0x0)
                 optee_smc_do_call_with_arg() {
                   tee_get_drvdata(); (ret=0xffff000002e55800)
                   tee_shm_get_va(); (ret=0xffff000002909000)
                   tee_shm_get_va(); (ret=0xffff000002909060)
                   optee_cq_wait_init(); (ret=0xffff000002e55910)
                   optee_smccc_smc(); (ret=0xffff0004)
                   tee_get_drvdata(); (ret=0xffff000002e55800)
                   optee_smccc_smc(); (ret=0xffff0004)
                   tee_get_drvdata(); (ret=0xffff000002e55800)
                   optee_smccc_smc(); (ret=0xffff0004)
                   tee_get_drvdata(); (ret=0xffff000002e55800)
                   optee_smccc_smc(); (ret=0xffff0004)
                   tee_get_drvdata(); (ret=0xffff000002e55800)
                   optee_smccc_smc(); (ret=0xffff0004)
     ... continues sending this forever ...
     ... Hit ^C to stop recording ...
                   tee_get_drvdata(); (ret=0xffff000002e55800)
                   optee_smccc_smc() {

[1] https://docs.u-boot.org/en/latest/develop/uefi/uefi.html#using-op-tee-for-efi-variables

Thanks in advance,

The most common problem with this is miscompiling the tee_supplicant
application.
Since we don't know if the system has an RPMB, we emulate it in the
tee_supplicant. How did you get the supplicant and can you check if it
was compiled with RPMB_EMU=0 or 1?

I'm using the tee-supplicant provided by the fedora package which is
built with ` -DRPMB_EMU=0`, I think that's correct, right?

Thanks,
   Enric

Thanks
/Ilias

quoted

   Enric