LCU13: An Introduction to ARM Trusted Firmware
25 likes•31,244 views
The document provides an overview of the Arm Trusted Firmware for Armv8-A, detailing its role as a reference implementation of secure software and emphasizing the need for standardization across various platforms. It discusses challenges such as rewriting firmware, integrating multiple software components, and the importance of a standardized interface for power management and system operations. The document also highlights the collaborative nature of the project, which is intended to facilitate easier integration and foster community development through an open-source model.
LCU13: An Introduction to ARM Trusted Firmware
- 1. 1 ARM Trusted Firmware for ARMv8-A LCU13 – 28th October 2013 Andrew Thoelke
- 2. 2 ARM Trusted Firmware Reference implementation of secure world software for ARMv8-A, including Exception Level 3 (EL3) software. Various ARM interface standards Power State Coordination Interface (PSCI) Trusted Board Boot Requirements (TBBR) Secure Monitor code Designed for porting to other implementations Continue collaborative development as an Open Source project licensed under BSD https://github.com/ARM-software/arm-trusted-firmware
- 3. 3 ARM Trusted Firmware Firmware on ARM SoCs Why now, why ARMv8-A? ARM Trusted Firmware overview Where are we now and what’s next
- 4. 4 ARM Trusted Firmware Firmware on ARM SoCs Why now, why ARMv8-A? ARM Trusted Firmware overview Where are we now and what’s next
- 5. 5 A quick primer on ARM architecture How Linux would like to think it is running on ARM ARMv6 ARM SoC svc usr Non-Secure AppAppApp AppAppApp OS OS
- 6. 6 A quick primer on ARM architecture Now that we have KVM/Xen on ARMv7 it looks like this ARMv7 ARM SoC hyp svc usr Non-Secure AppAppApp AppAppApp OS OS Hypervisor
- 7. 7 A quick primer on ARM architecture But that is forgetting the software in secure execution states Effectively opaque to OS/hypervisor: it looks like firmware ARMv7 ARM SoC hyp svc usrusr Non-Secure Secure AppAppApp AppAppApp OS OS Hypervisor AppAppApp svc mon Trusted OS Secure Firmware Secure Monitor
- 8. 8 Who writes the software? Operating System code from multiple vendors needs to be integrated … ARMv7 ARM SoC hyp svc usrusr Non-Secure Secure AppAppApp AppAppApp OS OS Hypervisor AppAppApp svc mon Trusted OS Secure Firmware Secure Monitor Windows Linux Android QNX
- 9. 9 Who writes the software? … with hypervisor code from multiple virtualisation vendors which needs to be integrated … ARMv7 ARM SoC hyp svc usrusr Non-Secure Secure AppAppApp AppAppApp OS OS Hypervisor AppAppApp svc mon Trusted OS Secure Firmware Secure Monitor Hyper-V Xen, KVM, VMware …
- 10. 10 Who writes the software? … with secure software from multiple vendors to create each product ARMv7 ARM SoC hyp svc usrusr Non-Secure Secure AppAppApp AppAppApp OS OS Hypervisor AppAppApp svc mon Trusted OS Secure Firmware Secure Monitor OEMs Silicon providers Trusted OS vendors
- 11. 11 Firmware is fragmented … with secure software from multiple vendors to create each product ARMv7 ARM SoC hyp svc usrusr Non-Secure Secure AppAppApp AppAppApp OS OS Hypervisor AppAppApp svc mon Trusted OS Secure Firmware Secure Monitor OEMs Silicon providers Trusted OS vendors Today in ARM products the secure firmware code is tightly integrated Resulting in distinct software integration effort for each SoC/TOS/OS combination OEM provides additional secure requirements…
- 12. 12 Introduce ARMv8-A ARMv8-A introduces a new set of AArch64 execution states The same software integration is needed AArch32 AArch64 ARM SoC hyp svc usrusr Non-Secure Secure AppAppApp AppAppApp OS OS Hypervisor AppAppApp svc mon Trusted OS Secure Firmware Secure Monitor EL2 EL1 EL0EL0 Non-Secure Secure AppAppApp AppAppApp OS OS Hypervisor AppAppApp EL3 Secure Monitor EL1 Trusted OS Secure Firmware ROM Firmware Secure Firmware
- 13. 13 ARM Trusted Firmware Firmware on ARM SoCs Why now, why ARMv8-A? ARM Trusted Firmware overview Where are we now and what’s next
- 14. 14 Challenge #1: Rewriting the Firmware To use AArch64, EL3 must be AArch64 AArch64 demands a different approach in the Secure Monitor EL1 (operating system) processor state must saved and restored by the Secure Monitor software Separation of the Trusted OS at Secure-EL1 from the Secure Monitor at EL3 requires a redesign of the interaction between the Trusted OS and Monitor Everyone writing secure privileged code has some substantial work to do – it’s not just a port of ARM assembler code to A64 instructions How much of this code is common?
- 15. 15 Challenge #2: A Need to Standardize A single kernel image has to work on all platforms – including the ones that have not been created yet Particularly for Enterprise systems This demands that interaction with the hardware platform is standardized around specified peripheral and firmware interfaces ARM has been creating some of these standards to make this possible: SMC Calling Convention – to enable standard and vendor specific firmware services to coexist PSCI – a firmware interface for CPU power control Working to define support for ARM systems in existing standards such as UEFI and ACPI How many implementations of the standards do we need? Is there a reference implementation?
- 16. 16 SMC Calling Convention Defines a standard calling convention Secure Monitor Calls in ARMv7 and ARMv8-A: Register use for parameters and return values, use of immediate Defines a partitioning of function ID space to allow multiple vendors to coexist in secure firmware OEMs, SiPs and Trusted OS vendors Providing number of services e.g. Standard firmware services (e.g. power management) Trusted OS Errata management Spec available from ARM infocenter: http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html
- 17. 17 S-EL1 Power State Coordination Interface Defines a standard interface for making power management requests across exception levels/operating systems Supports virtualisation and a communications with between normal and secure world Allows secure firmware to arbitrate power management requests from secure and non- secure software Default method for power control in Linux AArch64 kernel EL2 EL3 EL1 Secure Platform FW Trusted OS Rich OS kernel Hypervisor Add/Remove cores Secondary boot Idle Shutdown Reset Spec available today in ARM infocenter: http://infocenter.arm.com/help/topic/com.arm.doc.den0022b/index.html
- 18. 18 Challenge #3: Dealing with bugs Working around hardware errata involves firmware may require setting secure processor state during boot may require runtime access to secure processor registers during OS execution – is the firmware call standard across SoCs? Errata do not always show up before a product is released can the firmware be updated? Secure firmware isn’t exempt from defects either Some firmware functionality is common across SoCs – multiple implementations provides multiple opportunities for defects
- 19. 19 Taking the Opportunity Reduce duplicated effort by standardizing on a single implementation framework for EL3 software for ARMv8-A Provide reference implementations and test suites for standard interfaces and firmware behaviour Provide reference secure initialisation code, including errata handling, for ARM CPUs and system peripherals A suitably designed, portable implementation will allow easier integration of the various pieces of secure software A demonstration of a multi-stage authenticated boot flow will encourage the use of updatable firmware in products The diversity of integration needs is best met by an open collaboration
- 20. 20 ARM Trusted Firmware Firmware on ARM SoCs Why now, why ARMv8-A? ARM Trusted Firmware overview Where are we now and what’s next
- 21. 21 ARM Trusted Firmware Architecture EL3 Firmware - BL31 (Secure Monitor) SMC Interface Service Router Other EL3 Interfaces Interrupt Handler World Switcher PSCI Pwr Ctrl Driver EL3 Arch Context Save/Restore Normal World Trusted World Interface Usage External Interface EL1 Execution Secure EL1 Execution EL2 Execution KeyGlossary BL - Boot Loader EDK2 - EFI Development Kit 2 EL - Exception Level NV - Non-Volatile PSCI - Power State Control Interface SMC - Secure Monitor Call UEFI - Unified Enhanced Firmware Interface EL3 Execution Potential Interface UEFI - BL33 UEFI Secure Boot EDK2 Core I/O Drivers Boot ROM - BL1 Trusted Board Boot 1 Trusted Boot Firmware - BL2 Trusted Board Boot 2 Cold/Warm Boot Detection NV Storage Driver Boot Time Arch + Platform Init Temp SMC Handler Boot Time Arch + Platform Init Test Trusted OS - BL32 PSCI Test Service Router TOS Interface S-EL1 Arch Context Save/Restore Interrupt Handler Runtime Arch + Platform Init Test Suite – BL33_ALT PSCI Tests EL1 Arch Context Save/Restore EL2 Arch Context Save/Restore Other Tests Interrupt Handler Runtime Arch + Platform InitException Trapper
- 22. 22 EL3 Firmware - BL31 (Secure Monitor) SMC Interface Service Router Other EL3 Interfaces Interrupt Handler World Switcher PSCI Pwr Ctrl Driver EL3 Arch Context Save/Restore Normal World Trusted World Interface Usage External Interface EL1 Execution Secure EL1 Execution EL2 Execution KeyGlossary BL - Boot Loader EDK2 - EFI Development Kit 2 EL - Exception Level NV - Non-Volatile PSCI - Power State Control Interface SMC - Secure Monitor Call UEFI - Unified Enhanced Firmware Interface EL3 Execution Potential Interface UEFI - BL33 UEFI Secure Boot EDK2 Core I/O Drivers Boot ROM - BL1 Trusted Board Boot 1 Trusted Boot Firmware - BL2 Trusted Board Boot 2 Cold/Warm Boot Detection NV Storage Driver Boot Time Arch + Platform Init Temp SMC Handler Boot Time Arch + Platform Init Test Trusted OS - BL32 PSCI Test Service Router TOS Interface S-EL1 Arch Context Save/Restore Interrupt Handler Runtime Arch + Platform Init Test Suite – BL33_ALT PSCI Tests EL1 Arch Context Save/Restore EL2 Arch Context Save/Restore Other Tests Interrupt Handler Runtime Arch + Platform InitException Trapper ARM Trusted Firmware version 0.2 Not Available Yet Partially Available
- 23. 23 ARM Trusted Firmware Firmware on ARM SoCs Why now, why ARMv8-A? ARM Trusted Firmware overview Where are we now and what’s next
- 24. 24 Firmware Availability Binary delivery in Sep’13 Linaro AArch64 OpenEmbedded release FVP Base models only (AEMv8 and Cortex A57/A53) PSCI v0.2: CPU_ON/OFF support, for MP boot and Linux CPU hotplug GICv3 configuration (AEMv8 model) for OS driver development UEFI used as normal world bootloader Source code published 25th October 2013 under BSD license https://github.com/ARM-software/arm-trusted-firmware November 2013 updates PSCI v0.2: CPU_SUSPEND for Linux CPU idle Foundation_v8 (new 2013 model) support Future Complete implementation of the PSCI specification Secure memory, Secure monitor, Test Trusted OS & Secure interrupts Booting the firmware from a block device
- 25. 25 ARM Trusted Firmware project The current release (v0.2) is an first implementation Limited functionality; not yet optimized; not yet hardened ARM to continue development in collaboration with interested parties to benefit all developers working with ARMv8-A TrustZone software Please Provide Feedback
- 26. 26 ARM Trusted Firmware at LCU13 Thursday 11am – 1pm, GT America 2 Deep Dive into ARM Trusted Firmware Technical tour through the design and implementation In the meantime… Find us at Connect: Andrew Thoelke, Dan Handley, Charles Garcia-Tobin Jason Parker, Vincent Korstanje Code: https://github.com/ARM-software/arm-trusted-firmware Feedback: via the GitHub issue tracker or through your ARM representative