Resource: LCU13 Name: An Introduction to ARM Trusted Firmware Date: 28-10-2013 Speaker: Andrew Thoelke Video: http://www.youtube.com/watch?v=q32BEMMxmfw

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