Hi Patrick,
On 2/9/21 9:08 AM, Patrick DELAUNAY wrote:
[snip]
For information, today the STMicroelectronics expected that the boot
sequence for secure boot
(with closed STM32MP1 devices) is the trusted boot chain.
TF-A (BL2) => OP-TEE or => U-Boot => OS
TF-A (BL32)
BL2 is authenticated by ROM code, with EDCSA support.
I next OpenSTLinux release (and soon after in upstream)
STMicroelectronics will add FIP support
for STM32MP15x; TF-A FIP allows to boot Kernel after TF-A BL2 if you
want to skip U-Boot
TF-A (BL2) => FIP (OP-TEE + Kernel)
And the FIP allow authentication with certificate for 'secured boot'
with a complete chain of trust.
https://trustedfirmware-a.readthedocs.io/en/latest/index.html
So the ECDSA support in SPL for STM32MP15x will be not actively
supported by STMicroelectronics for product design.
The boot flow I'm working on will use an authenticated BL2 as well:
ROM -> SPL(BL2) -> FIT(OP-TEE -> Linux)
I'm using this to boot to a 3D application very fast (a couple of
seconds max). It's really cool. I even wrote a utility for signing SPL
images for the ROM code to check [1].
I had looked at FIP images briefly a few months back. I didn't see any
advantage over the FIT format. I also wanted to have as little code as
possible, so avoiding TF-A made sense. There were also some major issues
with syncing the clock tree between linux and TF-A. TF-A was a beautiful
disaster. Maybe that changed, but given I have a working proof of
concept, I doubt I'll be re-engineering the boot flow.
I realize there won't be any STM support for SPL. openstlinux seems to
have moved away from SPL. I've gotten a lot of enthusiastic support from
u-boot members, as a number of people seem to really like this chip
(meself included).
Alex
[1] https://github.com/mrnuke/stm32mp-keygen
