[RFC PATCH] stm32mp1: Replace STM32IMAGE config with TFABOOT_FIP

[Etienne Carriere]

Hello Alex,

Thanks for sharing your thoughts.


On Fri, 3 Sept 2021 at 19:47, Alex G. <mr.nuke.me at gmail.com> wrote:
>
> On 9/3/21 10:32 AM, Marek Vasut wrote:
> > On 9/1/21 11:07 AM, Patrick DELAUNAY wrote:
> >> On 8/31/21 6:42 PM, Marek Vasut wrote:
>
> >>> I would argue that the U-Boot crypto code went through multiple >>
> >>> independent security reviews, personally I trust that more than code
> >>> fully controlled and maintained by any one single company, so I am
> >>> not buying the security constraint argument here.
> >>
> >>
> >> When I talk about security, it is not crypto code, but some security
> >> features as isolation between cortex A and Cortex M, key
> >> infractructure, trusted environment execution, secure update.
> >
> > I'll offload this answer to Alexandru, however as far as I can tell, SPL
> > is perfectly capable of starting the TEE and setting up the correct
> > execution levels etc. too.
>
> There is not a unisex size for security. It's all driven by
> requirements.

I fully agree.

>  My client wants certain pieces of code to be
> triple-encrypted with a full-body latex suit (and kevlar reinforced). I
> don't care about A and M separation, clock control and other fancies. In
> fact it's better that those are handled by linux because that helps with
> boot time, considerably.
>
> I can achieve that by ECDSA-signing the FSBL, and putting that critical
> code in TEE trusted applications. I don't need to TiVO-ize the device,
> lock the kernel, etc. Because of that, can incorporate GPL-v3 programs
> and libraries, and generally have more flexibility in the software
> architecture.

TF-A sources are available on the web. You can fetch them, and even
incorporate GPL source, provided you comply with the terms.
I must admit that upstream changes incorporating GPL code will likely
be quite discussed.

>
> I'm more than happy to deal with the TZC and ETZPC in SPL, because SPL
> is fast. Again, this is really driven by the totality of requirements.
>
> TF-A is a pretty poor solution in this case for a trio of reasons. When
> I was trying TF-A, I found a small bug in assembly code. I tried to
> submit a fix, which was immediately rejected. I was required to sign a
> CLA granting patent rights. I can't do that legally on behalf of my
> client. This puts TF-A on a take it or leave it basis, such that I can't

True, at the time it was not handy to contribute. TF-A now relies on
Developer's Certificate of Origin 1.1.
So anyone can post a change proposal. It's true that the review
process is less flexible than the well established U-Boot ML.

> fix problems with it.
>
> TF-A also requires me to use a new file format (FIP). It's a binary
> format which is already a huge red flag for me. It seems very similar to
> a concatenation of EFI HOBs and FFS, and it makes no sense why TF-A
> would not have just gone with those more established formats. Is it
> secure? I don't know. It's pretty new to start with, and much more
> inflexible than FIT. Why would I recommend to my client an unproven
> format, when FIT has already gone through several CVEs and is more
> widely supported? Definitely not.
>
> Then TF-A is one extra codebase in the secure path of the system. Do I
> want to have to deal with an extra program bringing its own possible
> flaws on holes? Not really.

On 64bit, the system needs TF-A as secure monitor (BL31) so TF-A
package is already part of the system build for these.
TF-A also boots platforms that do not use U-Boot in the boot sequence.
For them, adding SPL would be adding a extra codebase.

>
> The official STM wiki seems to document the "how" of security: "Use TF-A
> and TEE, all others unsupported". It doesn't explain the "why". The
> "how" is what my client complained it takes two minutes to boot. And
> those two minutes are the reason I'm working on this.
>
> It would help to have better explained options with their corresponding
> security implications. Even absent that, SPL is perfectly capable of
> starting a secure system. I think it's also more flexible.

I agree SPL could be used in place of TF-A BL2, if one prefers this
one over that one.
SPL would need to pass a few boot information to secure world firmware
image (TF-A BL31), as those TF-A BL2 passes to it's BL31 stage.
as those SPL passes the U-Boot proper :)


regards,
etienne





>
> Let's get serious. Without SPL, I wouldn't have been able to boot linux
> in one second, with a secure OS.
>
> Alex