Technical Overview of the Trusted Firmware: A Class Open Source Project
Presents technical Overview of the Trusted Firmware: A Class Open Source Project and evaluates key implications for security practitioners.
Summary
### Overview Sandrine Bavyer (Staff Software Engineer at Arm) and Joanna Farley (Engineering Manager at Arm) present a technical overview of the Trusted Firmware-A (TF-A) open-source project. TF-A serves as the reference implementation of firmware for Arm A-class processors (Cortex-A for client devices and Neoverse for infrastructure), aligning with Arm software, architectural, and hardware standards. Originating around 2013, the project transitioned in 2018 to an open governance model under trustedfirmware.org. It features a master tree released on a six-month cycle under a BSD 3-Clause license, supported by continuous integration and Developer Certificate of Origin (DCO) contributions.
### Key Topics - **Architecture and Governance:** Implementing Arm TrustZone with isolated normal and secure worlds across Exception Levels (EL0 to EL3). The codebase spans roughly 350,000 lines (one-third core, two-thirds platform code across ~30 platforms from 16+ silicon vendors). - **Boot Flow and Trusted Boot:** Multi-stage bootloader flow (BL1, BL2, BL31) enforcing a chain of trust compliant with the Trusted Boot Firmware Update (TBFU) specification. - **Power Management and Exceptions:** Support for Power State Coordination Interface (PSCI), System Control and Management Interface (SCMI), and Software Delegated Exception Interface (SDEI). - **Generic Firmware Initiative:** Decoupling platform-specific binaries using dynamic device tree configurations and the Firmware Configuration (fconf) framework. - **Secure World Re-architecting:** Leveraging Armv8.4-A secure virtualization (Secure EL2) and the PSA FFA specification to isolate secure partitions via a Secure Partition Manager (SPM).
### Technical Details - **Boot Stages and Cryptographic Trust:** BL1 resides in ROM and authenticates BL2, which in turn loads and authenticates runtime resident BL31 (EL3 monitor). Boot authentication utilizes a cryptographically signed chain of trust originating from the Root of Trust Public Key (ROTPK). If authentication fails, boot immediately halts. Multiple signing domains and build-time image encryption with load-time decryption are also supported. - **Runtime Management:** BL31 orchestrates synchronous transitions between normal and secure worlds through Secure Monitor Calls (SMC). TF-A implements PSCI runtime services for core idle, hotplugging, and resets, coordinating power transitions between rich OSes and trusted OSes. Systems with a System Control Processor (SCP) interface via an SCMI driver. Critical asynchronous events and hardware errors (such as RAS memory failures) are dispatched to normal-world OS/hypervisors via SDEI callbacks. - **fconf Framework:** To eliminate monolithic per-platform header builds, TF-A adopts device tree files parsed at runtime using libfdt. Modules register extraction callbacks via `fconf_register_populator` into a specific linker section. Upon boot, callbacks populate internal structures (e.g., hardware topology), which are queried across modules using `fconf_get_property`. Constrained platforms can alternatively embed static data structures while retaining the identical getter API. - **PSA FFA and Secure Virtualization:** To mitigate code bloat, reduce EL3 attack surface, and eliminate implicit trust between third-party Trusted OSes and EL3 firmware, services migrate to Secure EL0 partitions. Managed by an SPM running at Secure EL2 (with Hafnium adopted as the reference SPM), partitions operate in isolated execution contexts and address spaces with least-privilege translation tables and filtered physical interrupts. Standardized communication is established using the Platform Security Architecture Firmware Framework for A-class (PSA FFA).
### Takeaways TF-A provides foundational reference security firmware for Arm A-class devices while addressing platform fragmentation. Recent advancements focus on moving hardware settings into signed configuration device trees via fconf and modularizing secure services into isolated Secure EL0/EL2 partitions with PSA FFA, establishing least privilege and stronger isolation across diverse silicon ecosystems.
Related talks
The Linux Foundation·28 min
Mateusz Sadowski · Weekly Robotics
Details an Opinionated Overview of Open-Source Robotics and evaluates key implications for security practitioners.
The Linux Foundation·36 min
Shino Iwami
Analyzes methodologies to Grasp Overviews of OSS as Open Source Program Offices OSPOs and evaluates key implications for security practitioners.
The Linux Foundation·30 min
Explores overview of Intent-based Networks: Requirements, Researches, Standardizations & Open-source and evaluates key implications for security practitioners.


