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

[Simon Glass <sjg@chromium.org>]

Hi,

On Tue, 2 Jul 2019 at 11:42, Marek Vasut <marek.vasut@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

3. Over time we end up with binary blobs on ARM that are every bit as
impenetrable as what Intel used to have

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

So overall I support Jagan's proposal based on the current status quo.

Regards,
Simon