Hi Enric

On Tue, 12 Nov 2024 at 13:40, Enric Balletbo i Serra
[off-list ref] wrote:

Hi again,

On Tue, Nov 12, 2024 at 9:17 AM Enric Balletbo i Serra
[off-list ref] wrote:

quoted

Hi,

On Mon, Nov 11, 2024 at 3:26 PM Ilias Apalodimas
[off-list ref] wrote:

quoted

On Mon, 11 Nov 2024 at 16:13, Enric Balletbo i Serra
[off-list ref] wrote:

quoted

Hi,

Thanks a lot for your support.

You're welcome. FWIW I did test this in the past with an AM62x SoC.

Thanks for the info, maybe I can give it a try with my BeaglePlay then...

quoted

quoted

On Mon, Nov 11, 2024 at 12:01 PM Ilias Apalodimas
[off-list ref] wrote:

quoted

On Mon, 11 Nov 2024 at 10:21, Enric Balletbo i Serra
[off-list ref] wrote:

quoted

Hi Ilias,

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

quoted

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

Yes it does look wrong. Our compilation flags are
CFG_RPMB_FS=y CFG_RPMB_FS_DEV_ID=0 CFG_RPMB_WRITE_KEY=y
CFG_RPMB_TESTKEY=y CFG_REE_FS=n CFG_CORE_ARM64_PA_BITS=48
CFG_SCTLR_ALIGNMENT_CHECK=n

Mine are very similar

make CROSS_COMPILE="$CC32" CROSS_COMPILE64="$CC64" \
    PLATFORM=k3-j784s4 CFG_ARM64_core=y CFG_CONSOLE_UART=0x8 \
    CFG_RPMB_FS_DEV_ID=0 CFG_REE_FS=n CFG_RPMB_FS=y \
    CFG_RPMB_WRITE_KEY=y CFG_RPMB_TESTKEY=y \
    CFG_STMM_PATH=BL32_AP_MM.fd \
    CFG_CORE_HEAP_SIZE=524288 CFG_CORE_DYN_SHM=y CFG_SCTLR_ALIGNMENT_CHECK=n \
    CFG_TEE_CORE_LOG_LEVEL=4 CFG_TEE_CORE_DEBUG=y CFG_TEE_TA_LOG_LEVEL=4

There is a difference with CFG_CORE_ARM64_PA_BITS=48 , my platform defines it to

   core/arch/arm/plat-k3/conf.mk:$(call force,CFG_CORE_ARM64_PA_BITS,36)

But I don't think this is the problem.

quoted

The testkey etc aren't required if your board has a way of reading the
RPMB key from a secure location -- in fact, using the testkey is not
secure. Is the RPMB programmed on your board? Also can you make sure
CFG_RPMB_FS_DEV_ID needs to be 0? How many sd interfaces your board
has?

My board has two interfaces, an eMMC and a SD-card, 0 is indeed the
eMMC and I'm using the testkey which I assume was programmed the first
time I booted with all this. Unfortunately I lost the traces. But,
optee_rpmb works. I.e:

     => optee_rpmb write test 1234
     => optee_rpmb read test 4
     Read 4 bytes, value = 1234

quoted

IOW in U-Boot does 'mmc dev 0 && mmc info' print information for the
RPMB partition?

    => mmc dev 0
    switch to partitions #0, OK
    mmc0(part 0) is current device
    => mmc info
    Device: mmc@4f80000
    Manufacturer ID: 13
    OEM: 4e
    Name: G1M15L
    Bus Speed: 200000000
    Mode: HS400 (200MHz)
    Rd Block Len: 512
    MMC version 5.1
    High Capacity: Yes
    Capacity: 29.6 GiB
    Bus Width: 8-bit DDR
    Erase Group Size: 512 KiB
    HC WP Group Size: 8 MiB
    User Capacity: 29.6 GiB WRREL
    Boot Capacity: 31.5 MiB ENH
    RPMB Capacity: 4 MiB ENH
    Boot area 0 is not write protected
    Boot area 1 is not write protected
    => mmc list
    mmc@4f80000: 0 (eMMC)
    mmc@4fb0000: 1

Any interaction with efi gives me the same result (printenv -e,
efidebug, bootefi ...)

Yes, that makes sense, because variables fail to initialize -- which
is a core part of bringing up the EFI subsystem.

Can you recompile op-tee with CFG_RPMB_RESET_FAT and try again?

Unfortunately that didn't help, but I don't see this code being run.

That's weird, look below.

quoted

Who sets for the first place the uefi variables, is this u-boot
writing them to the rpmb? or is optee itself?

U-Boot sets the variables, but it does so via StandAloneMM.

quoted

I tried to compare the behaviour between optee_rpmb (works) and
efidebug (doesn't worrk). I see that the first thing optee_rpmb
command does is open a session against the TA application, something
that efidebug doesn't do, shouldn't efidebug do the same to access to
the rpmb device and read or write the efi variables?

That's a bit more complicated and explained to one of the blog posts I
pasted above.
We do open an OP-TEE session, but not for talking to a TA. We send the
messages to StandAloneMM, which then usese OPTEE RPMB APIs to write
the flash.

The weird thing is why OP-TEE does not format your RPMB when compiling
with that flag.
If done correctly, OP-TEE will wipe the RPMB contents the first time
it tries to access it.

Cheers
/Ilias

=> optee_rpmb read test 4
D/TC:? 0 tee_ta_init_pseudo_ta_session:303 Lookup pseudo TA
023f8f1a-292a-432b-8fc4-de8471358067
D/TC:? 0 ldelf_load_ldelf:110 ldelf load address 0x40007000
D/LD:  ldelf:142 Loading TS 023f8f1a-292a-432b-8fc4-de8471358067
F/TC:? 0 trace_syscall:147 syscall #3 (syscall_get_property)
F/TC:? 0 trace_syscall:147 syscall #5 (syscall_open_ta_session)
D/TC:? 0 ldelf_syscall_open_bin:163 Lookup user TA ELF
023f8f1a-292a-432b-8fc4-de8471358067 (early TA)
D/TC:? 0 ldelf_syscall_open_bin:167 res=0
F/TC:? 0 trace_syscall:147 syscall #7 (syscall_invoke_ta_command)
F/TC:? 0 read_compressed:178 1024 bytes
F/TC:? 0 read_compressed:178 1024 bytes
F/TC:? 0 read_compressed:178 1024 bytes
F/TC:? 0 read_compressed:178 1024 bytes
F/TC:? 0 trace_syscall:147 syscall #11 (syscall_mask_cancellation)
F/TC:? 0 trace_syscall:147 syscall #7 (syscall_invoke_ta_command)

=> efidebug query -bs -rt -nv
MMC: no card present
mmc_init: -123, time 2002
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

quoted

quoted

Thanks
/Ilias

quoted

=> efidebug query -bs -rt -nv
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
... stuck here ... I need to reset the board

Will continue to see if I can get more useful messages

Thanks,
  Enric

quoted

Thanks
/Ilias

quoted

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

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