Hi Ilias,

On Sat, Nov 9, 2024 at 1:31 AM Ilias Apalodimas
[off-list ref] wrote:

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

quoted

Hi Ilias,

Thanks for your quick answer.

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

quoted

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,

Are you talking about env variables? Perhaps you store them in the mmc
and not the RPMB partition?
There's some information here [0]

quoted

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?

U-Boot has two ways of storing EFI variables [0] . You can either
store them in a file or the RPMB partition. The correct thing to do,
since you want to use the RPMB, is enable CONFIG_EFI_MM_COMM_TEE. I am
not sure why the hand happens, but one thing we can improve is figure
out why it hangs and print a useful message.
There are a number of reasons that might lead to a failure. Is the
RPMB key programmed on your board? Have a look at this [1] in case it
helps

quoted

quoted

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

If I had to guess, OP-TEE doesn't store the variables in the RPMB, can
you compile it with a bit more debugging enabled?

Here is a log with CFG_TEE_CORE_LOG_LEVEL=4, CFG_TEE_CORE_DEBUG=y and
CFG_TEE_TA_LOG_LEVEL=4

https://paste.centos.org/view/eed83a5b

At the beginning of the log I see

D/TC:0 0 check_ta_store:449 TA store: "REE"

Which looks wrong to me as I built optee with:
  CFG_REE_FS=n
  CFG_RPMB_FS_DEV_ID=0
  CFG_RPMB_FS=y

I'll try to add some more prints to verify if REE is used as a store
system, I assume this should say something about RPMB. Am I right with
this?

quoted

quoted

quoted

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?

Yes, this is correct. We fixed the Fedora package to compile the
supplicant correctly a while back.

[0] https://www.linaro.org/blog/uefi-secureboot-in-u-boot/
[1] https://apalos.github.io/Protected%20UEFI%20variables%20with%20U-Boot.html#Protected%20UEFI%20variables%20with%20U-Boot


Regards
/Ilias

quoted

Thanks,
   Enric

quoted

Thanks
/Ilias

quoted

   Enric