[RFC PATCH] stm32mp1: Replace STM32IMAGE config with TFABOOT_FIP

[Marek Vasut]

On 9/1/21 11:07 AM, Patrick DELAUNAY wrote:
> Hi Marek,

Hi,

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

By adding adding another component into the boot chain, the complexity 
increases.

> To guarantee the Cortex M security, the shared resource (as root clock 
> or regulator for example) need to be managed by a centralized element.

How come Linux cannot manage those resources, like on other vendors' 
SoCs, where Linux can do that just fine (namely e.g. iMX6SX, which is 
very similar to the MP1) ?

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

Linux is capable of managing both the PMIC and the CM4, what exactly is 
the problem ?

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

Neither of these APIs are mandatory on ARMv7a , so why force them onto 
users if Linux kernel can do the same without this extra complexity and 
extra code ?

> 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

U-Boot does have PSCI support, so why not just extend that code which 
you already have as part of the boot chain if you have to have PSCI 
support (which is optional on armv7a and definitely not needed to boot 
the kernel on armv7a) ?

If you were to do the above, you would have one bootloader code base 
under one license, not two disparate code bases with separate set of 
bugs and disparate licenses.

> 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 
What exactly would I be missing that cannot be done with U-Boot / SPL ?
This statement above is extremely vague and makes it look as if adding 
extra complexity was the only way, however so far I do not see anything 
that I would be missing on the MP1 with SPL.

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

This is not relevant here, this is downstream vendor BSP which is easy 
to ignore, including whatever policy it tries to enforce onto its consumers.

However, if this is a policy that ST is trying to enforce outside of the 
BSP and even on upstream users, then there has to be a justification for 
it, with clear pros and cons. So far, I only see the cons -- complexity, 
maintenance burden, duplication of effort, increased boot time, need to 
rework boot chain on existing systems, and I can go on -- I do not see 
any benefit this change would bring me, sorry.

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

I'll offload this answer to Alexandru, however as far as I can tell, SPL 
is perfectly capable of starting the TEE and setting up the correct 
execution levels etc. too.

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

All of this can be done perfectly well in Linux as well, so why hide 
this into difficult to inspect firmware ?

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

Yes, it is open source software that is _currently_ released also in 
source form. However, that also means that if someone gives me a 
pre-compiled blob of this software at any time, I have no legal way of 
getting the matching sources, they can just tell me off, because that is 
exactly what the permissive license allows them to do. And it also means 
that if sometimes in the future this will no longer be released in 
source form, I have a maintenance problem with my existing systems.

There is zero guarantee that neither of these scenarios will happen, and 
I cannot just hope it won't happen.

With U-Boot, which is GPLv2, I do have that guarantee -- if I have a 
blob, I have legal right to matching sources.

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

These two terms mean two very different things, please do not conflate them.

> and customers (SoM maker or other) manage their distribution.

I hope we can keep it that way, esp. in terms of not making optional 
software components look mandatory.

[...]