LCU13: An Introduction to ARM Trusted Firmware

1

ARM Trusted Firmware

for ARMv8-A LCU13 – 28th October 2013

Andrew Thoelke

2


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


Firmware on ARM SoCs

Why now, why ARMv8-A?

ARM Trusted Firmware overview

Where are we now and what’s next

4






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


Now that we have KVM/Xen on ARMv7 it looks like this

ARMv7

ARM SoC

hyp

svc

usr

Non-Secure


OS OS

Hypervisor

7


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


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


OS OS

Hypervisor

App App App

svc

mon Trusted OS

Secure

Firmware

Secure

Monitor

Windows

Linux

Android

QNX

9


… with hypervisor code from multiple virtualisation vendors

which needs to be integrated …

ARMv7

ARM SoC

hyp

svc

usr usr

Non-Secure Secure


OS OS

Hypervisor

App App App

svc

mon Trusted OS

Secure

Firmware

Secure

Monitor

Hyper-V

Xen, KVM,

VMware …

10


… with secure software from multiple vendors to create each

product

ARMv7

ARM SoC

hyp

svc

usr usr

Non-Secure Secure


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


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


OS OS

Hypervisor

App App App

svc

mon Trusted OS

Secure

Firmware

Secure

Monitor

EL2

EL1

EL0 EL0

Non-Secure Secure


OS OS

Hypervisor

App App App

EL3

Secure

Monitor

EL1 Trusted OS

Secure

Firmware

ROM

Firmware

Secure

Firmware

13






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

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






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






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


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:


Feedback:

via the GitHub issue tracker or through your ARM representative








https://github.com/ARM-software/arm-trusted-firmware/issues

https://github.com/ARM-software/arm-trusted-firmware/issues

Date post:	10-May-2015
Category:	Technology
Upload:	linaro
View:	2,303 times
Download:	24 times

LCU13: An Introduction to ARM Trusted Firmware

Technology