[RFC PATCH] stm32mp1: Replace STM32IMAGE config with TFABOOT_FIP
Marek Vasut
marex at denx.de
Tue Aug 31 18:42:16 CEST 2021
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.
[...]
More information about the U-Boot
mailing list