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

[Marek Vasut]

On 9/5/19 2:54 AM, André Przywara wrote:
> On 04/09/2019 18:56, Marek Vasut wrote:
>> On 9/4/19 7:32 PM, Andre Przywara wrote:
> 
> Hi Marek,

Hi,

>>>> 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?
> 
> But this is what we actually do on those platforms: SPL is loaded by the
> BootROM, PLLs and bus clocks are set up in SPL, then DRAM and MMC are
> initialised, then we load U-Boot proper and ATF BL31.
> BL31 does SMP init and errata workaround, and stays resident in EL3 to
> provide PSCI services.

Then why is there so much init code in ATF plat/ and drivers/ ? I think
that should rather be in the U-Boot SPL instead of being duplicated in ATF.

> This BL31-only model is considered a perfectly fine way of using ATF.
> 
>>>> 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.
> 
> BSD was simply chosen because basically every vendor said they would not
> (be able to) use GPL licensed code for their firmware.
> So it was BSD license or no (Open Source) firmware at all.
> You might find that sad (I do), but that's what it is.

There are quite a few GPL licensed bootloaders and they are doing quite
fine I think, so it's not that clear cut.

>> It seems like some platforms even went down this path already and only
>> released blobs, hence, no security fixes etc.
> 
> If you don't control the platform (servers), then you still have some
> power as a customer to ask for releasing the firmware source. AFAIK this
> is well understood by the vendors, as it is a good selling point against
> x86.

Every single time I asked a vendor for changes to BSD-licensed sources,
I either got silent treatment or was told off. Hence, I am not a fan of
BSD license at all.

> And what I meant above is that this is in contrast to x86, where most of
> the firmware ("BIOS") is proprietary and consists of many third-party
> parts. So even when your system vendor wanted, it couldn't possibly
> publish the code. With the core firmware being Open Source, you have a
> much better chance of getting the source.
> If the vendor doesn't want to give code away, it would just use
> proprietary code anyway, probably of much worse quality.

Considering how many various blobs recent ARM64 systems are growing
(e.g. DDR4 init is usually a blob, some "secure" firmwares are blobs and
so on), I don't think BSD licensed bootloader will help here.

>>>> 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 ?
> 
> "as open as possible", yes. As mentioned above, this might probably be
> as good as it can get.

I would very much prefer for those security components to have
guaranteed source availability, but with BSD license, this is not gonna
happen.

-- 
Best regards,
Marek Vasut