Hi Marek,
On 8/31/21 6:42 PM, Marek Vasut wrote:
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.
- 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.
Our concerns is not a licensing issue (BSD vs GPL) but firmware complexity to manage Cortex A (Linux) + Cortex M (RTOS) and shared ressources.
To guarantee the Cortex M security, the shared resource (as root clock or regulator for example) need to be managed by a centralized element.
It is the same for low power mode = to manage each possible step for Cortex M + Cortex A and PMIC security, the low power sequence are executed in secure side.
=> it is done in our ecosystem for STM32MP15x platform in secure monitor (OP-TEE - the preferred one - or SPMin) based on SCMI and PSCI api called by Linux kernel generic driver.
These API are NOT supported by SPL / U-Boot, it is the reason of the restrictions = I have only implement a limited PSCI support to start the kernel
You can continue to use SPL on STM32MP15 (at the current upstream level) but with limited features.
but only the boot with TF-A is supported / promoted by STMicroelectronics on the STM32MP family.
These restriction are already announced to STMicroelectronics customers since OpenSTLinux v1.2 I think.
For example in https://wiki.st.com/stm32mpu-ecosystem-v2/wiki/STM32MP15_ecosystem_release_n...
Basic boot has been removed since STM32MP15-ecosystem-v2.0.0,
if you were using basic boot with U-BOOT-SPL to load U-BOOT and the Kernel,
then you need to use now the ST reference boot scheme in replacing U-BOOT-SPL by TF-A
as FSBL as explained in Boot chain overview.
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.
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.
Some part is already done in Linux with call SCMI / PSCI api.
Some part is done in secured firmware: DDR self refresh entry sequence / root clock deactivation / PMIC access on secured I2C.
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.
TF-A in OpenSTLinux is delivered as source, you can recompile it => no blob delivery for STMicroelectronics
https://github.com/STMicroelectronics/arm-trusted-firmware
And we upstream all the TF-A developments (work in progress).
For us, OpenSTLinux is not only "open source" but "free software"....
and customers (SoM maker or other) manage their distribution.
[...]
Regards.
Patrick