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.

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