lcu13: an introduction to arm trusted firmware
Post on 10-May-2015
2.312 Views
Preview:
DESCRIPTION
TRANSCRIPT
1
ARM Trusted Firmware
for ARMv8-A LCU13 – 28th October 2013
Andrew Thoelke
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
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
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
A quick primer on ARM architecture
How Linux would like to think it is running on ARM
ARMv6
ARM SoC
svc
usr
Non-Secure
App App App App App App
OS OS
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
App App App App App App
OS OS
Hypervisor
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
usr usr
Non-Secure Secure
App App App App App App
OS OS
Hypervisor
App App App
svc
mon Trusted OS
Secure
Firmware
Secure
Monitor
8
Who writes the software?
Operating System code from multiple vendors needs to be
integrated …
ARMv7
ARM SoC
hyp
svc
usr usr
Non-Secure Secure
App App App App App App
OS OS
Hypervisor
App App App
svc
mon Trusted OS
Secure
Firmware
Secure
Monitor
Windows
Linux
Android
QNX
9
Who writes the software?
… with hypervisor code from multiple virtualisation vendors
which needs to be integrated …
ARMv7
ARM SoC
hyp
svc
usr usr
Non-Secure Secure
App App App App App App
OS OS
Hypervisor
App App App
svc
mon Trusted OS
Secure
Firmware
Secure
Monitor
Hyper-V
Xen, KVM,
VMware …
10
Who writes the software?
… with secure software from multiple vendors to create each
product
ARMv7
ARM SoC
hyp
svc
usr usr
Non-Secure Secure
App App App App App App
OS OS
Hypervisor
App App App
svc
mon Trusted OS
Secure
Firmware
Secure
Monitor
OEMs
Silicon providers
Trusted OS
vendors
11
Firmware is fragmented
… with secure software from multiple vendors to create each
product
ARMv7
ARM SoC
hyp
svc
usr usr
Non-Secure Secure
App App App App App App
OS OS
Hypervisor
App App App
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
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
usr usr
Non-Secure Secure
App App App App App App
OS OS
Hypervisor
App App App
svc
mon Trusted OS
Secure
Firmware
Secure
Monitor
EL2
EL1
EL0 EL0
Non-Secure Secure
App App App App App App
OS OS
Hypervisor
App App App
EL3
Secure
Monitor
EL1 Trusted OS
Secure
Firmware
ROM
Firmware
Secure
Firmware
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
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
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
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
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
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
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
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
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
KeyGlossaryBL - 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
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
KeyGlossaryBL - 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
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
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
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
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
top related