OP-TEE 3.13: Is CFG_STMM_PATH still working?

[super119]

Following #3973, I'm trying to enable UEFI StMM in OP-TEE as a secure partition.
But I found that the StMM doesn't get loaded at all. After some digging, I realized that CFG_SECURE_PARTITION should be enabled otherwise secure_partition.c won't be compiled. Along with this path, I enabled these configs to eliminate the build errors:

• $(call force,CFG_EMBEDDED_TS,y)
• $(call force,CFG_CORE_FFA,y)
• $(call force,CFG_CORE_SEL1_SPMC,y)

Then I hit an error which I have no idea how to fix:
....../optee_os/core/arch/arm/kernel/entry_a64.S:260: undefined reference to `ffa_secondary_cpu_boot_req'
The function "ffa_secondary_cpu_boot_req" is defined in "core/arch/arm/plat-vexpress/fvp_spmc_pm.c", and "fvp_spmc_pm.c" is guarded by "PLATFORM_FLAVOR_fvp".
I don't think enabling "PLATFORM_FLAVOR_fvp" is the right choice because that looks like a platform-dependent config item. So this makes me wondering what is the correct way to run UEFI-MM as a secure partition in OP-TEE?

I noticed that in the latest version of OP-TEE, there are SPMC support added. I tried that as well (with SPMD in ATF) but also hit lots of issues... so again, what is the recommended way right now to enable the SP(secure partition) functionality in OP-TEE?

Thanks for any comments.

[jenswi-linaro]

StMM doesn't work with FF-A yet, that's still work in progress.
We have a CI build with:
PLATFORM=vexpress-qemu_armv8a CFG_STMM_PATH=BL32_AP_MM.fd CFG_RPMB_FS=y CFG_CORE_HEAP_ SIZE=524288 CFG_TEE_RAM_VA_SIZE=0x00400000

Please try without FF-A enabled and TF-A compiled with the normal OP-TEE Dispatcher.

[super119]

So does that mean "CFG_STMM_PATH" only work on platform: vexpress-qemu_armv8a ?
BTW, is BL32_AP_MM.fd an efi executable?

[jenswi-linaro]

So does that mean "CFG_STMM_PATH" only work on platform: vexpress-qemu_armv8a ?

Let's check with @apalos

BTW, is BL32_AP_MM.fd an efi executable?

Yes

[apalos]

So does that mean "CFG_STMM_PATH" only work on platform: vexpress-qemu_armv8a ?

Let's check with @apalos

BTW, is BL32_AP_MM.fd an efi executable?

Yes

It's not supported by default. The problem is that QEMU has no native way of presenting an RPMB interface to U-Boot. What BL32_AP_MM.fd currently does is try to store the EFI variables in an RPMB.

You can take a look at https://git.linaro.org/people/ilias.apalodimas/efi_optee_variables.git/tree/patches
This adds a very hacky patch on top of U-Boot, which emulates the RPMB accesses. That being said RPMB wont be accessible into linux, since it will spawn it's own supplicant and it's own 'RPMB-emulation'. The EFI variables will be accesible for reading at runtime though, since u-boot copies them on memory before launching the kernel

[super119]

Thanks guys. So maybe dumb questions:

• Can we make CFG_STMM_PATH work for all platforms?
• Once FF-A/SPMC stuffs are done, will CFG_STMM_PATH be deprecated?

[etienne-lms]

(edited)

• Can we make CFG_STMM_PATH work for all platforms?

StMM can be useful only for platforms with some secure storage other than REE_FS (not supported in u-boot/uefi), hence RPMB_FS is the only upstream alternative and relevant only for platform that have one.

StMM from edk2 sources currently doesn't for Arm/32bit. Patches are on-going (reviewed but waiting for merge).

Once FF-A/SPMC stuffs are done, will CFG_STMM_PATH be deprecated?

I think there will exist platforms that will not enable FF-A/SPMC and still use StMM secure partition. I thinking about some armv7-a and armv8.1/2/3 platforms.

[apalos]

Thanks guys. So maybe dumb questions:

* Can we make CFG_STMM_PATH work for all platforms?

Yes you can. The BL32_AP_MM.fd is fully self-relocatable and the only thing it does is send a bunch of SVC calls down to op-tee to trigger the RPMB API and it's read/write capabilities. So the same .fd file can be used across all platforms. There's a guide in optee-docs on how to enable the entire functionality for U-Boot.
Keep in mind that U-Boot only uses dynamic shared memory, so make sure your op-tee port defines that.

* Once FF-A/SPMC stuffs are done, will CFG_STMM_PATH be deprecated?

I am not sure how it will look there, maybe @jenswi-linaro has a better understanding.

[jenswi-linaro]

* Once FF-A/SPMC stuffs are done, will CFG_STMM_PATH be deprecated?

I am not sure how it will look there, maybe @jenswi-linaro has a better understanding.

Eventually it will, but it may take a bit longer than just implementing FF-A. StMM must then be a proper SP in order to be loaded as a normal SP and all that.

[super119]

Thanks guys, close the issue.