[RFC PATCH] stm32mp1: Replace STM32IMAGE config with TFABOOT_FIP

[Alex G.]

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. 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.

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 
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.

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.

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

Alex