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

Thu Sep 5 23:14:35 UTC 2019

On Thu, 5 Sep 2019 14:26:41 +0200
Marek Vasut <marek.vasut at gmail.com> wrote:

Hi,

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

Anything in particular you are looking at?
ATF handles more platforms that those just using the BL31 only approach.
Also there are platforms that don't even support U-Boot.
So those have more code in their plat/ directory, and bring their own
drivers.

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

For which platforms? Servers? High end network appliances?

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

Yes, I can see that from your response and the answers down here ;-)
But as mentioned before: GPL was not an option for those components.

Cheers,
Andre.

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