From mboxrd@z Thu Jan  1 00:00:00 1970
From: Alex G. <mr.nuke.me@gmail.com>
Date: Tue, 9 Feb 2021 15:28:56 -0600
Subject: [PATCH 0/5] Enable ECDSA FIT verification for stm32mp
In-Reply-To: <1e9f9eb1-b871-0ed0-a833-b79f2f8fcd55@foss.st.com>
References: <20210111154137.621732-1-mr.nuke.me@gmail.com>
 <1e9f9eb1-b871-0ed0-a833-b79f2f8fcd55@foss.st.com>
Message-ID: <82ec8f8b-ddaf-96ad-e5f4-55d27f73f87a@gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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