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

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

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

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

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

LCU13: An Introduction to ARM Trusted Firmware

You are reading a preview.

Check these out next

LCU13: An Introduction to ARM Trusted Firmware

More Related Content

Slideshows for you (20)

Similar to LCU13: An Introduction to ARM Trusted Firmware (20)

More from Linaro (20)

Recently uploaded (20)