[PATCH 2/3] image: Add support for starting TFA BL31 as fitImage loadables

[Quentin Schulz]

Hi Marek, Biju,

On 1/13/25 2:31 PM, Biju Das wrote:
> Hi Marex,
> 
>> -----Original Message-----
>> From: Marek Vasut <marek.vasut at mailbox.org>
>> Sent: 13 January 2025 12:40
>> Subject: Re: [PATCH 2/3] image: Add support for starting TFA BL31 as fitImage loadables
>>
>> On 1/13/25 1:15 PM, Biju Das wrote:
>>> Hi Marex,
>>>
>>> Thanks for the patch
>>>
>>>> -----Original Message-----
>>>> From: U-Boot <u-boot-bounces at lists.denx.de> On Behalf Of Marek Vasut
>>>> Sent: 12 January 2025 22:37
>>>> Subject: [PATCH 2/3] image: Add support for starting TFA BL31 as
>>>> fitImage loadables
>>>>
>>>> Add support for starting TFA from U-Boot running in EL3 as part of
>>>> fitImage boot, so the user can start U-Boot in the highest privilege
>>>> level on the platform, bundle TFA, Linux, DT into a single fitImage and boot such a bundle as a
>> whole.
>>>>
>>>> There are two main benefits of this approach. First is the ability to
>>>> run U-Boot in EL3, where it has unrestricted access to the entire
>>>> system and can act as a useful debug tool, as it was always intendedSecure)
>>>> to be used. Second is the ability to easily and safely update of any component in the fitImage, be
>> it TFA, Linux or DT.
>>>
>>> In this case, who will do switching from secure world to normal world, u-boot?
>>> Do you have any link to the u-boot patch from secure to normal world
>>> switching with kernel entry point passed to BL31?
>>>
>>> Otherwise, kernel, also will be executing in secure world mode.
>> See 3/3 , U-Boot runs in EL3 , before starting kernel it jumps into TFA
>> BL31 , TFA BL31 does its setup and switches from EL3 to EL2 , TFA BL31 returns to U-Boot
>> armv8_switch_to_el2 which checks if this code is running in EL2 (it is) and does the last few steps
>> before starting kernel, and then finally jumps to the kernel .
> 
> Thanks for the explanation. I missed the details in 3/3.
> 
> BL2(Secure)->U-boot(Secure)->BL31(Secure)-->U-boot(Normal)->Linux Kernel(Normal)
> 

If the fit image is missing the TF-A loadable property for example (and 
maybe in other corner case scenario?) the kernel will start in EL3 
though and fail very early since it needs TF-A BL31 for a few things. 
However, part of the kernel code will actually run in EL3 and that could 
be enough to mess things up with a carefully crafted kernel image.

Is this actually possible or am I making stuff up? If it is possible, 
isn't that an issue?

Currently, this is already possible and has happened a few times already 
at my company with people forgetting to bundle TF-A in U-Boot and then 
the kernel would boot but stops early (no console output even IIRC). But 
the bootloader is not THAT often updated in the field compared to kernel 
(especially if coming from distros) which would now allow to store the 
TF-A, so this opens an even bigger can of worms? In a way, it allows to 
update TF-A likely more securely (which is VERY welcome on Rockchip for 
example, where we usually start new SoC bringups with a blob from 
Rockchip and then have upstream TF-A catch up a few years later. Having 
BL31 part of U-Boot is a huge pain because it is difficult for some 
devices to do safe updates of U-Boot) but may introduce some bigger 
security issues?

Finally, another question, what happens if we have a U-Boot with bundled 
TF-A BL31 AND it tries to boot a fitimage with a TF-A BL31 loadable? 
Should we only allow to load tf-a BL31 if running from EL3 (meaning if 
in EL2, TF-A is expected to be already running)?

Cheers,
Quentin