[PATCH 0/5] Enable ECDSA FIT verification for stm32mp

[Alex G. <mr.nuke.me@gmail.com>]

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