Pdf Manual Located Under the “Documentation” Directory
Total Page:16
File Type:pdf, Size:1020Kb
Trusted Firmware-A unknown Sep 24, 2021 CONTENTS 1 About 1 2 Getting Started 25 3 Processes & Policies 107 4 Components 135 5 System Design 239 6 Platform Ports 337 7 Performance & Testing 445 8 Security Advisories 453 9 Design Documents 465 10 Threat Model 469 11 Change Log & Release Notes 495 12 Glossary 571 13 License 575 14 Getting Started 577 Index 579 i ii CHAPTER ONE ABOUT 1.1 Feature Overview This page provides an overview of the current TF-A feature set. For a full description of these features and their implementation details, please see the documents that are part of the Components and System Design chapters. The Change Log & Release Notes provides details of changes made since the last release. 1.1.1 Current features • Initialization of the secure world, for example exception vectors, control registers and interrupts for the platform. • Library support for CPU specific reset and power down sequences. This includes support for errata workarounds and the latest Arm DynamIQ CPUs. • Drivers to enable standard initialization of Arm System IP, for example Generic Interrupt Controller (GIC), Cache Coherent Interconnect (CCI), Cache Coherent Network (CCN), Network Interconnect (NIC) and Trust- Zone Controller (TZC). • A generic SCMI driver to interface with conforming power controllers, for example the Arm System Control Processor (SCP). • SMC (Secure Monitor Call) handling, conforming to the SMC Calling Convention using an EL3 runtime services framework. • PSCI library support for CPU, cluster and system power management use-cases. This library is pre-integrated with the AArch64 EL3 Runtime Software, and is also suitable for integration with other AArch32 EL3 Runtime Software, for example an AArch32 Secure OS. • A minimal AArch32 Secure Payload (SP_MIN) to demonstrate PSCI library integration with AArch32 EL3 Runtime Software. • Secure Monitor library code such as world switching, EL1 context management and interrupt routing. When a Secure-EL1 Payload (SP) is present, for example a Secure OS, the AArch64 EL3 Runtime Software must be integrated with a Secure Payload Dispatcher (SPD) component to customize the interaction with the SP. • A Test SP and SPD to demonstrate AArch64 Secure Monitor functionality and SP interaction with PSCI. • SPDs for the OP-TEE Secure OS, NVIDIA Trusted Little Kernel and Trusty Secure OS. • A Trusted Board Boot implementation, conforming to all mandatory TBBR requirements. This includes im- age authentication, Firmware Update (or recovery mode), and packaging of the various firmware images into a Firmware Image Package (FIP). • Pre-integration of TBB with the Arm CryptoCell product, to take advantage of its hardware Root of Trust and crypto acceleration services. 1 Trusted Firmware-A • Reliability, Availability, and Serviceability (RAS) functionality, including – A Secure Partition Manager (SPM) to manage Secure Partitions in Secure-EL0, which can be used to implement simple management and security services. – An SDEI dispatcher to route interrupt-based SDEI events. – An Exception Handling Framework (EHF) that allows dispatching of EL3 interrupts to their registered handlers, to facilitate firmware-first error handling. • A dynamic configuration framework that enables each of the firmware images to be configured atruntimeif required by the platform. It also enables loading of a hardware configuration (for example, a kernel device tree) as part of the FIP, to be passed through the firmware stages. This feature is now incorporated inside the firmware configuration framework (fconf), which is still flagged as experimental. • Support for alternative boot flows, for example to support platforms where the EL3 Runtime Software isloaded using other firmware or a separate secure system processor, or where a non-TF-A ROM expects BL2 tobeloaded at EL3. • Support for the GCC, LLVM and Arm Compiler 6 toolchains. • Support for combining several libraries into a “romlib” image that may be shared across images to reduce memory footprint. The romlib image is stored in ROM but is accessed through a jump-table that may be stored in read- write memory, allowing for the library code to be patched. • Support for the Secure Partition Manager Dispatcher (SPMD) component as a new standard service. • Support for ARMv8.3 pointer authentication in the normal and secure worlds. The use of pointer authentication in the normal world is enabled whenever architectural support is available, without the need for additional build flags. Use of pointer authentication in the secure world remains an experimental configuration at this timeand requires the BRANCH_PROTECTION option to be set to non-zero. • Position-Independent Executable (PIE) support. Currently for BL2, BL31, and TSP, with further support to be added in a future release. 1.1.2 Still to come • Support for additional platforms. • Refinements to Position Independent Executable (PIE) support. • Continued support for the FF-A v1.0 (formally known as SPCI) specification, to enable the use of secure partition management in the secure world. • Documentation enhancements. • Ongoing support for new architectural features, CPUs and System IP. • Ongoing support for new Arm system architecture specifications. • Ongoing security hardening, optimization and quality improvements. Copyright (c) 2019-2021, Arm Limited. All rights reserved. 2 Chapter 1. About Trusted Firmware-A 1.2 Release Processes 1.2.1 Project Release Cadence The project currently aims to do a release once every 6 months which will be tagged on the master branch. There will be a code freeze (stop merging non-essential changes) up to 4 weeks prior to the target release date. The release candidates will start appearing after this and only bug fixes or updates required for the release will be merged. The maintainers are free to use their judgement on what changes are essential for the release. A release branch may be created after code freeze if there are significant changes that need merging onto the integration branch during the merge window. The release testing will be performed on release candidates and depending on issues found, additional release candidates may be created to fix the issues. |<----------6 months---------->| |<---4 weeks--->||<---4 weeks--->| +-----------------------------------------------------------> time |||| code freeze ver w.x code freeze ver y.z Upcoming Releases These are the estimated dates for the upcoming release. These may change depending on project requirement and partner feedback. Release Version Target Date Expected Code Freeze v2.0 1st week of Oct ‘18 1st week of Sep ‘18 v2.1 5th week of Mar ‘19 1st week of Mar ‘19 v2.2 4th week of Oct ‘19 1st week of Oct ‘19 v2.3 4th week of Apr ‘20 1st week of Apr ‘20 v2.4 2nd week of Nov ‘20 4th week of Oct ‘20 v2.5 3rd week of May ‘21 5th week of Apr ‘21 v2.6 4th week of Oct ‘21 1st week of Oct ‘21 1.2.2 Removal of Deprecated Interfaces As mentioned in the Platform Compatibility Policy, this is a live document cataloging all the deprecated interfaces in TF-A project and the Release version after which it will be removed. Interface Deprecation Date Removed after Release Comments Copyright (c) 2018-2021, Arm Limited and Contributors. All rights reserved. 1.2. Release Processes 3 Trusted Firmware-A 1.3 Project Maintenance Trusted Firmware-A (TF-A) is an open governance community project. All contributions are ultimately merged by the maintainers listed below. Technical ownership of most parts of the codebase falls on the code owners listed below. An acknowledgement from these code owners is required before the maintainers merge a contribution. More details may be found in the Project Maintenance Process document. 1.3.1 Maintainers Mail Dan Handley <[email protected]> GitHub ID danh-arm Mail Soby Mathew <[email protected]> GitHub ID soby-mathew Mail Sandrine Bailleux <[email protected]> GitHub ID sandrine-bailleux-arm Mail Alexei Fedorov <[email protected]> GitHub ID AlexeiFedorov Mail Manish Pandey <[email protected]> GitHub ID manish-pandey-arm Mail Mark Dykes <[email protected]> GitHub ID mardyk01 Mail Olivier Deprez <[email protected]> GitHub ID odeprez Mail Bipin Ravi <[email protected]> GitHub ID bipinravi-arm Mail Joanna Farley <[email protected]> GitHub ID joannafarley-arm Mail Julius Werner <[email protected]> GitHub ID jwerner-chromium Mail Varun Wadekar <[email protected]> GitHub ID vwadekar Mail Andre Przywara <[email protected]> GitHub ID Andre-ARM Mail Lauren Wehrmeister <[email protected]> GitHub ID laurenw-arm Mail Madhukar Pappireddy <[email protected]> GitHub ID madhukar-Arm Mail Raghu Krishnamurthy <[email protected]> 4 Chapter 1. About Trusted Firmware-A GitHub ID raghuncstate 1.3.2 Code owners Common Code Armv7-A architecture port Mail Etienne Carriere <[email protected]> GitHub ID etienne-lms Build Definitions for CMake Build System Mail Javier Almansa Sobrino <[email protected]> GitHub ID javieralso-arm Mail Chris Kay <[email protected]> GitHub ID CJKay Files / Software Delegated Exception Interface (SDEI) Mail Mark Dykes <[email protected]> GitHub ID mardyk01 Mail John Powell <[email protected]> GitHub ID john-powell-arm Files services/std_svc/sdei/ Trusted Boot Mail Sandrine Bailleux <[email protected]> GitHub ID sandrine-bailleux-arm Mail Manish Pandey <[email protected]> GitHub ID manish-pandey-arm Mail Manish Badarkhe <[email protected]> GitHub ID ManishVB-Arm Files drivers/auth/ 1.3. Project Maintenance