enable secure boot in ATF

[jiankang]

hello,

I'm working on S32g platform  board.

I need to enable secure boot in ATF boot process.

after adding  "TRUSTED_BOARD_BOOT=1 GENERATE_COT=1" to build command. I meet some error as below:

| aarch64-wrs-linux-ld.bfd: /home/jiankang.huang/workspace/s32g/build-batman/tmp-glibc/work/cortexa53-wrs-linux/atf-s32g/2.5-r0/build/batman/release/bl2/bl2_main.o: in function `bl2_main':
| bl2_main.c:(.text.bl2_main+0x38): undefined reference to `auth_mod_init'
| bl2_main.c:(.text.bl2_main+0x38): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `auth_mod_init'
| aarch64-wrs-linux-ld.bfd: /home/jiankang.huang/workspace/s32g/build-batman/tmp-glibc/work/cortexa53-wrs-linux/atf-s32g/2.5-r0/build/batman/release/bl2/bl_common.o: in function `load_auth_image_recursive':
| bl_common.c:(.text.load_auth_image_recursive+0x24): undefined reference to `auth_mod_get_parent_id'
| bl_common.c:(.text.load_auth_image_recursive+0x24): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `auth_mod_get_parent_id'
| aarch64-wrs-linux-ld.bfd: bl_common.c:(.text.load_auth_image_recursive+0xd0): undefined reference to `auth_mod_verify_img'
| bl_common.c:(.text.load_auth_image_recursive+0xd0): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `auth_mod_verify_img'
| Makefile:1125: recipe for target '/home/jiankang.huang/workspace/s32g/build-batman/tmp-glibc/work/cortexa53-wrs-linux/atf-s32g/2.5-r0/build/batman/release/bl2/bl2.elf' failed
| make: *** [/home/jiankang.huang/workspace/s32g/build-batman/tmp-glibc/work/cortexa53-wrs-linux/atf-s32g/2.5-r0/build/batman/release/bl2/bl2.elf] Error 1

it seems that original BSP release, don't support build atf with Trusted board boot feature ?

please help guide me how to enable  Trusted board boot feature in ATF build process.

thanks a lot.

[Daniel-Aguirre]

Hi,

Could you elaborate more on what "Trusted board boot" refers to? We are seeing the following description which we would like confirmation on (link: 5.8. Trusted Board Boot — Trusted Firmware-A documentation)

Also, could you provide which BSP version are you working with? Also, are you using a provided NXP board? Or is it a custom design?

We are looking into the Linux BSP33.0 User Manual For S32G2 Platform and we are not seeing any support for the specific parameter "TRUSTED_BOARD_BOOT", which make us think it is not supported.

There is a specific chapter regarding secure boot [10.2 Secure Boot, Page 67, Linux BSP33.0 User Manual for S32G2 Platforms, 07/2022] which provides information on how to build-it. This uses the HSE FW provided by NXP which is the one in charge of the authentication mechanism.

Please, let us know.

[jiankang]

hello,

yes, I'm talking about the feature refer to (link: 5.8. Trusted Board Boot — Trusted Firmware-A documentation)

And I'm working on custom board based on s32g2 evp and using BSP32.(anyway, I checked BSP34 is the same situation)

hmm, previously, for LS and imx series it's OK to use Trusted board boot feature.

if s32g platform don't support this feature for certain, I must turn to another way for secure boot verify.

or if s32g may suport it later ?

please help to confirm

[Daniel-Aguirre]

Hi,

Given S32G is a different platform, could be the reason why this is different from both LS and IMX.

As said before, the S32G integrates the "secure boot" with the HSE Firmware [Page 67, Linux BSP 33.0 User Manual for S32G2 platform, 07/2022]:

"Secure boot refers to a two-stage process of successive authentication of the U-Boot and Linux kernel images. This process requires a "root of trust", which is known to be secure.

Each image is authenticated by the preceding step. Thus, the secure boot flow is the following:
1. BootROM passes control over to HSE FW;
2. HSE FW authenticates the U-Boot image;
3. U-Boot authenticates the Kernel image. "

Which is the recommended implementation of a secure boot using S32G platform.

Please, let us know.

[jiankang]

hello，

In the recommended implementation of a secure boot process there is no atf/optee ?

but we should support the entire boot process verification, including bootRom-》 BL2-》BL31(secure monitor)-》BL32(optee)-》BL33(uboot)-》kernel-》...

is there any recommended implementation ?

[Daniel-Aguirre]

Hi,

ATF is also supported on the S32G platform. It is shown on chapter 23 from the Linux User Manual.

The same for OP-TEE, it is supported.

Please, let us know.

[jiankang]

hello

as mentioned before：

Each image is authenticated by the preceding step. Thus, the secure boot flow is the following:
1. BootROM passes control over to HSE FW;
2. HSE FW authenticates the U-Boot image;
3. U-Boot authenticates the Kernel image. "

in the secure boot process above，there is no atf/optee image authentication.

so I need to add atf/optee images authentication by myself ? or is there any recommened solution provided by NXP ?

thanks.

[Daniel-Aguirre]

Hi,

We may not be understanding the specifics of your requirements. The BSP that is provided by NXP includes ATF+u-boot, with this same image you are able to implement the HSE FW (also provided by NXP).

HSE-FW will run over the HSE_M7 core (or M7_0), meaning that (if enabled) once BootROM finishes, it will pass the control over to the HSE_M7 running HSE-FW which then will proceed to fetch the application image after authentication.

The Linux image can be described as an application image, for which it will be executed once HSE-FW authenticates it, then ATF+u-boot+kernel sequence should be run. Might be that the description is not so descriptive as to the HSE sequence itself but given this is described on the HSE manuals (which are confidential) might be the reason.

Please, let us know if this information was helpful or not.

[Jj17]

Hello,

I've also been digging the secure boot. I seems to me that the secure boot suggested by the BSP (39) is not secure.

The provided hse_secboot binary loads the whole fip including BL2, BL31, (BL32 ,) BL33 in a single SMR. I see that the HSE will verify the whole FIP, load it into RAM and then jump into BL2. However vanilla BL2 go back to the persistent storage to look for the FIP and then load the rest of the bootloaders.

Thus without the TRUSTED_BOARD_BOOT enable (which doesn't seems to be supported), BL2 will not verify what it loads, and BL2 will not natively look for the verified FIP loaded by the HSE.