[RFC PATCH] stm32mp1: Replace STM32IMAGE config with TFABOOT_FIP

[Patrick DELAUNAY]

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

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_note_-_v2.1.0

      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