Secure boot: mutable extlinux.conf in bootfs during updates allows boot flow manipulation - recommended solution?

[maxim-senec]

Description

Hello,

we are currently integrating secure boot on an STM32MP15-based platform using the ST OpenSTLinux ecosystem (TF-A + OP-TEE + U-Boot + RAUC / ST update solution here: https://github.com/STMicroelectronics/meta-st-ota/).

During this work, we identified a potential gap in the chain of trust related to the boot filesystem (bootfs), specifically the use of a mutable extlinux.conf.

Problem

In our current setup:

• TF-A authenticates FIP (OP-TEE + U-Boot)
• U-Boot supports FIT signature verification for kernel / DTB / initramfs
• extlinux.conf is stored in bootfs (ext4) and remains writable - this post-install.sh changes rootfs partuuid after each update. 
• U-Boot uses extlinux.conf to select kernel / DTB and to define kernel command line (`root=PARTUUID=e91c4e10...`). This PARTUUID is changed after the update. 

With secure boot enabled, if extlinux remains mutable, it cannot be signature-protected, which violates the chain of trust.

---

Question

What is the recommended approach in ST architecture to handle this?

Specifically:

1. Is there an ST-recommended way to protect or authenticate extlinux.conf?
2. Are there existing patches for this problem? 

---

Any guidance, best practices, or references to ST-secured designs would be highly appreciated.

Thanks in advance!

[Christophe Guibout]

 

Hello @maxim-senec,

The quick answer would be to build the two bootfs images (A and B) and make them available on the server, so each image is properly signed. This solution also addresses the read-only filesystem issue.

I understand your point, and I will look for a better solution.

Best regards,
Christophe