[U-Boot] What if ATF can be part of U-Boot source, like SPL?

[Marek Vasut <marek.vasut@gmail.com>]

On 9/4/19 7:32 PM, Andre Przywara wrote:

[...]

>> I have been avoiding this thread but today I attended a talk on ATF
>> and ARM's approach in general. ARM seems to be moving towards an
>> approach of providing increasingly complex source code to add more
>> layers of security software to fully round out two mostly separate
>> worlds (secure and normal).
>>
>> Oddly enough Intel was also there talking about how they are breaking
>> things down into pieces and slowly releasing more things into the open
>> source world.
>>
>> I came away with the impression that the two companies are going in
>> different directions. ARM seems to be heading where Intel was and
>> Intel is heading back. This is a gross simplification of course.
>>
>> To me it seems that the following scenario might play out:
>>
>> 1. ARM releases new ATF versions as source drops that firmware
>> projects like U-Boot expected to take. In fact, not even U-Boot...this
>> is just users picking up whatever they find
>>
>> 2. ATF keeps getting more complex, adding its own drivers for serial,
>> storage, etc., duplicating and perhaps conflicting with those in
>> U-Boot
> 
> A bit like U-Boot, ATF can look quite differently on the various platforms:
> - There are platforms like Arm's Juno or the fastmodel, where ATF does some loading. This is mostly for features like secure boot or secure payloads (OP-Tee). Typically we don't even use U-Boot primarily on those platforms (but EDK II instead).
> - There are platforms (low end SoCs like Allwinner, Rockchip, for instance) which don't do any loading at all, actually rely on other code (SPL?) to load ATF itself.
> 
> So I don't see how this would duplicate effort or even conflict.

So why don't we put all the platform init code into U-Boot SPL, which
already has all the loading code and only load this ATF BL31 with SPL?

>> 3. Over time we end up with binary blobs on ARM that are every bit as
>> impenetrable as what Intel used to have
> 
> I am not quite sure I follow how you come from 2. to 3. Was there something in the presentation (I guess OSFC?) you are referring to?
> In contrast to the x86 world the firmware is actually Open Source based, so you actually have a realistic chance to rebuild and/or verify it. If this is not true in a particular case, poke your vendor.

I thought ATF was designed to be BSD-licensed to allow vendors to take
all the open source contributions, benefit from it, but also allow the
vendors to never release their changes if they so desire.

It seems like some platforms even went down this path already and only
released blobs, hence, no security fixes etc.

>> 4. Firmware security and open-sourceness suffers, overall.
>>
>> One approach might be for ATF to split into a library which can be
>> linked into a new U-Boot phase and a driver/init bit that could be
>> used for other bootloaders, whatever they might be.
>>
>> But in the meantime, I think it makes more sense to incorporate the
>> relevant parts of ATF into U-Boot and maintain them there, only for
>> the platforms that U-Boot supports. If ATF starts using GUIDs and the
>> like, we at least have somewhere to hide :-)
> 
> What are the relevant parts, exactly? Do you want to rip them out? Use git submodules?
> For reasons I detailed before, I doubt the viability of the practical aspect alone.
> 
> But on top of that, I see that ATF and U-Boot address two separate areas: CPU initialisation and secure world management on one side, and a very versatile bootloader running in the non-secure world on the other. Keeping them separate allows a clean separation and lets each project focus on its core functionality.
> 
> I understand that this separation is not always as clear or as well implemented on every platform, but at least we should aim at this.
Shouldn't the "secure world" management be as open as possible then ?

-- 
Best regards,
Marek Vasut