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

[Andre Przywara]

On Tue, 3 Sep 2019 19:17:14 -0700
Simon Glass <sjg at chromium.org> wrote:

Hi Simon,

> On Tue, 2 Jul 2019 at 11:42, Marek Vasut <marek.vasut at gmail.com> wrote:
> >
> > On 6/30/19 3:38 AM, André Przywara wrote:  
> > > On 30/06/2019 00:03, Marek Vasut wrote:
> > >
> > > Marek,
> > >
> > > you seem to be quite defensive in your answer  
> >
> > I am just correcting the mistakes I perceive in the previous email.
> >  
> > >, but I was just talking
> > > against merging ATF into U-Boot, not against U-Boot - I think we agree
> > > on this. I don't think there is much of a point in comparing ATF and
> > > U-Boot, as the two do not compete against each other. They just
> > > complement each other nicely, hence we use ATF and save us the burden of
> > > having to reprogram something in U-Boot.  
> >
> > I suspect I answered those already in the thread.
> >  
> > >> On 6/29/19 8:49 PM, André Przywara wrote:  
> > >>> On 29/06/2019 16:02, Jagan Teki wrote:  
> > >>>> In terms of code maintenance and development feasibility it is always
> > >>>> a better approach to have out-of-tree code or binary to be part of
> > >>>> in-house source tree.  
> > >>>
> > >>> I am not sure this is really true. If I get you right, you want to
> > >>> mirror and sync the ATF source into the U-Boot tree, which sounds like a
> > >>> pain:
> > >>> - ATF development is quite dynamic, with just shy of 1000 commits alone
> > >>> this year.  
> > >>
> > >> I don't think ATF development is anywhere near as dynamic as U-Boot,
> > >> there's over 1000 commits in each U-Boot release, with quarterly release
> > >> cycle.  
> > >
> > > Wasn't comparing, just saying that it's nothing you want to sync
> > > regularly. Unlike libfdt, for instance.
> > >  
> > >>> This would mean constant churn of keeping the source up-to-date.
> > >>> - The overlap of U-Boot and ATF users is not that big: ATF has support
> > >>> for a lot more platforms (most of them typically paired with EDK-2),  
> > >>
> > >> Can you elaborate on how you came to this conclusion ? Last time I
> > >> counted (a few days ago, in ATF master), the upstream ATF supported some
> > >> low tens of boards, upstream U-Boot around a thousand. And then there's
> > >> the part where ATF is ARM-centric while U-Boot is platform-agnostic.  
> > >
> > > I now see that my wording was unclear: ATF supports more platforms than
> > > those that also use U-Boot. So you pull in code that you will never need.  
> >
> > I think s/more/different/
> >
> > [...]
> >  
> > >>> I am not questioning the current design, but just want to point out that
> > >>> this might not be best thing since sliced bread.  
> > >>
> > >> It would certainly help if we could have one, or a few, bootloader
> > >> project(s) and work on those few, to make them great. Currently there
> > >> are many, each with a limited developer community. Adding more does not
> > >> help, it only increases the fragmentation and the mess.  
> > >
> > > And that's exactly the point of ATF: You can use the tested PSCI code,
> > > the secure GIC setup and all those core errata workarounds and spare
> > > yourself from wrongly implementing this on your own.  
> >
> > Which is a benefit of one single vendor being in control of everything?
> > Surely, this single vendor has perfect engineers that make no mistakes,
> > right? I think we had that before, and it didn't work out very well :)
> >  
> > > Also ATF is not a bootloader, it explicitly leaves out that part.
> > >  
> > >>>> So can we
> > >>>> do the same thing for ATF on ARM64 SoCs?
> > >>>>
> > >>>> We are using ATF (on Allwinner) to switch EL3 to EL2 for start loading
> > >>>> U-Boot proper and minimal PSCI  
> > >>>
> > >>> Minimal PSCI? TF-A is the full fledged reference implementation of PSCI,
> > >>> it always supports the newest revisions, including Spectre/Meltdown
> > >>> support. This alone is a killer argument for me to use ATF.  
> > >>
> > >> So ARM creates new PSCI version, ARM implements it into ARM trusted
> > >> firmware, and then presents it to the users as the latest greatest.  
> > >
> > > Yes, that's the definition of a reference implementation. And it's Open
> > > Source with a permissive license.  
> >
> > Yes, it's Open Source and it's not Free Software, which is unfortunate.
> > It allows disasters like vendors taking ATF, reaping all the benefits of
> > external contributions, but releasing only closed-source blobs and
> > giving everyone who wants to study the code or change it the finger.
> >  
> > >> That sounds a bit like the old windows development model -- one company
> > >> does everything and then presents it to developers for them to consume.  
> > >
> > > PSCI is an interface, with a publicly available spec. You can go ahead
> > > and implement it yourself - and U-Boot does. And by using PSCI, you win
> > > so much, because SMP in *any* kernel suddenly becomes very straightforward.  
> >
> > Just about like ACPI on x86.
> >  
> > > So if you mean with "Windows model" that there is a standard that makes
> > > everyone's life easier by providing compatibility and well defined
> > > interfaces - I agree. For everything else I fail to see how it would
> > > compare.  
> >
> > I meant more like one company in control of everything, just providing
> > consumables for developers.
> >  
> > >> My recent impression of ATF development is there is no community around
> > >> ATF, so I presume there is no interest from collecting any feedback on
> > >> the PSCI development from people outside of ARM, is that right ?  
> > >
> > > ATF and PSCI are two quite separate things, it's just that the former
> > > implements the latter.
> > > And I am not sure how the community aspect relates to the feedback
> > > process. Section 1.1 in the PSCI PDF tells you about how to report back
> > > any comments.
> > >
> > > Anything in particular you want to discuss about PSCI? Happy to make
> > > contacts.  
> >
> > I am talking about ATF.  
> 
> 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.

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

Cheers,
Andre,

> So overall I support Jagan's proposal based on the current status quo.
> 
> Regards,
> Simon