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

[Matteo Carlini]

Hi Simon and all,

> I have been avoiding this thread but today I attended a talk on ATF and
> ARM's approach in general.

For the benefits of others, that was me talking at the OSFC conference (video and slides should appear soon here: https://osfc.io/talks/trustedfirmware-org-a-collaborative-effort-into-firmware-security-and-the-path-towards-standardized-open-source-firmware-on-arm).
Had a chat with Simon and Jagan afterwards, so repeating my answers here for the records.

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

The requirement of having more complex source code running in the Secure world comes from our partners (SoC vendors, ODMs, OSVs...Google included).
For example, multi-tenancy in the Secure world (the possibility of running multiple Trusted OSs owned by different vendors) on an Android phone is a real requirement raised by many manufacturers and by Google. Arm is trying to fulfil this requirement by providing both an architecture and a clean reference implementation to support this and to protect the Normal world from attacks (malicious code) running in the Secure world.
Worth noticing that all will be developed, reviewed and tested in public as part of the TrustedFirmware.org project, the new "home" of Trusted Firmware-A (TF-A, the former Arm Trusted Firmware).

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

As explained verbally, Arm is going into the same direction it has always gone: open source every piece of software running on an Arm platform (from the very first line of code), including all the Power Management software implementation (PSCI into Trusted Firmware, SCMI into the SCP firmware project - https://github.com/ARM-software/SCP-firmware) and encouraging all our partners to do the same for their platforms ports.
You can run a full open source software stack on any Arm platform that has upstream support available and the direction is not going to change with more software running in the Secure world (Secure EL2 included)...it will just be some more open source software.

> 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

That's an accurate description (apart from the fact that releases will be tagged by the TrustedFirmware.org community project, not by Arm as such). We have the Linux Kernel model in mind (despite the BSD license topic) and the requirement to reliably point to a precise Trusted Firmware version running on an Arm device, as much as you do with the Kernel. This is practically impossible today due to the number of different implementations deployed on every device by different manufacturers. And that's the problem we are trying to fix.

> 2. ATF keeps getting more complex, adding its own drivers for serial, storage,
> etc., duplicating and perhaps conflicting with those in U-Boot

Apart from platforms support, the additional software to be developed in the Secure world is meant to implement Arm architecture and Arm specifications, not to bloat the code with unnecessary drivers...moreover, as Andre pointed out, Trusted Firmware runs on many non-U-Boot platforms, so there *might* be overlaps for things that are needed elsewhere.

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

That's definitely not our goal. We'd like to ease the audit/certification process and ultimately the security of the highest privileged firmware running on Arm, by encouraging our partners to adopt a clean EL3 (and in the future Secure EL2) generic firmware (ideally a specific x.y version) and moving all their proprietary/platform code elsewhere in lowest exception levels. That's the goal of the architecture we are working on (described in my talk) and we believe it would ultimately help the Arm firmware security ecosystem in general.
If by doing so, partners will still end up deploying binary blobs (signed, certified, whatever), these would be built from the corresponding open source project.
I don't see how the situation would be any worst that it is today with proprietary EL3 firmware binaries deployed everywhere (despite all the originating core code being upstream!). From my point of view, it could only evolve towards a more open situation...every partner that we gain on this approach will be a partner bought into more open firmware and increased security.

> 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.
[...]
> So overall I support Jagan's proposal based on the current status quo.

Bear in mind that TF-A is undergoing huge developments and it's definitely a well alive and dynamic project, it's not a stable library as libfdt to be copied and held for years with little maintenance.
We are adding support for all new Arm architectural security features (Armv8.3 Pointer Authentication, Armv8.5 BTI, Armv8.4 Secure EL2) for devices that will come out soon on the market.
Any out of tree fork would need to be maintained quite frequently and stay closely up to date with all recent changes.

The way we cope with the process of building and combining multiple firmware projects in Arm is to have some build/manifest scripts that pulls everything together from appropriate repos and build it in the right order with the proper options (have a look at the instructions here https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms.git/about/docs/user-guide.rst)

An alternate idea Simon have briefly proposed verbally to me is to harmonise TF-A and U-boot around the Kconfig build system. Simon feel free to expose it properly.
We are currently investigating the use of Kconfig for TF-A since the current build system is not scalable any longer, so that's something we can surely discuss together with the TF-A community.

And...yes, there's an ever growing community around Trusted Firmware, both for A-class and M-class, that goes well beyond Arm and very much favour collaboration and feedbacks from adopters, contributors, partners...you can reach the TF-A one here tf-a at lists.trustedfirmware.org, others here https://lists.trustedfirmware.org/mailman/listinfo.

Thanks
Matteo

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.