Re: [RFC PATCH] stm32mp1: Replace STM32IMAGE config with TFABOOT_FIP

[Marek Vasut <marex@denx.de>]

On 8/31/21 4:54 PM, Patrick DELAUNAY wrote:
> Hi Alexandru,

Hi,

> On 8/26/21 11:47 PM, Alexandru Gagniuc wrote:
>> Hi Patrick,
>>
>> I proposing a better fix fir the issues I outlined earlier, I made a
>> classification of the currently supported boot modes.
>>
>>     1) BL1 -> SPL -> U-Boot
>>     2) BL1 -> SPL -> OP-TEE
>> ---------------------------------------------------------------------
>> |  3) BL1 -> TF-A -> U-Boot                                         |
>> |  4) BL1 -> TF-A -> OP-TEE                                         |
>> | _________________________________________________________________ |
>> || 5) BL1 -> TF-A -> FIP container                                 ||
>> || CONFIG_TFABOOT_FIP                                              ||
>> ||_________________________________________________________________||
>> |                                                                   |
>> | CONFIG_TFABOOT                                                    |
>> ---------------------------------------------------------------------
>>
>> Here, I'm looking at FIP as a new boot mode. In order to avoid
>> breakage, any changes to support FIP it should naturally be done only
>> to this new path.
>>
>> This proposal contains several changes, but I've squashed them into
>> one for ease of discussion.
>>
>> This better matches the boot mode classification above.
> 
> 1) is supported but with many constraint for security part and low power 
> management
> 
>      it is not recommended for real product / it will be not supported 
> by STMicroelectronics

Does this mean ST will be cutting off their own customers who use this 
boot mode because they do not need/want additional complex 
problematically licensed components in their boot chain and/or ST will 
be forcing those customers into adding such unneeded/unwanted components 
unconditionally ?

I am strongly opposed to that.

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.

Regarding power management and low power modes, there is literally 
nothing preventing Linux from implementing those low power modes, so 
there is no reason to hide all that code in firmware, so I am not buying 
the low power argument either.

Finally, the argument that the component that is being forced upon 
everyone is "open source" is really turning any design with such a SoC 
into a huge risk.

There have been SoCs where the vendor took "open source" bootloader 
code, compiled a blob, released a blob and never gave out the sources, 
because it is "open source" and not "free software", the BSD license 
permits such practice, GPL does not. Whoever wanted to design a board or 
SoM with such a SoC, had to adjust their design to match that one blob. 
Of course, that also implies that any security problems were not fixable 
in that blob.

[...]