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