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) ...
3
ARM Trusted Firmware
 Firmware on ARM SoCs
 Why now, why ARMv8-A?
 ARM Trusted Firmware overview
 Where are we now a...
4
ARM Trusted Firmware
 Firmware on ARM SoCs
 Why now, why ARMv8-A?
 ARM Trusted Firmware overview
 Where are we now a...
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
A...
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-Se...
7
A quick primer on ARM architecture
But that is forgetting the software in secure execution states
Effectively opaque to ...
8
Who writes the software?
Operating System code from multiple vendors needs to be
integrated …
ARMv7
ARM SoC
hyp
svc
usru...
9
Who writes the software?
… with hypervisor code from multiple virtualisation vendors
which needs to be integrated …
ARMv...
10
Who writes the software?
… with secure software from multiple vendors to create each
product
ARMv7
ARM SoC
hyp
svc
usru...
11
Firmware is fragmented
… with secure software from multiple vendors to create each
product
ARMv7
ARM SoC
hyp
svc
usrusr...
12
Introduce ARMv8-A
ARMv8-A introduces a new set of AArch64 execution states
The same software integration is needed
AArc...
13
ARM Trusted Firmware
 Firmware on ARM SoCs
 Why now, why ARMv8-A?
 ARM Trusted Firmware overview
 Where are we now ...
14
Challenge #1: Rewriting the Firmware
 To use AArch64, EL3 must be AArch64
 AArch64 demands a different approach in th...
15
Challenge #2: A Need to Standardize
 A single kernel image has to work on all platforms –
including the ones that have...
16
SMC Calling Convention
 Defines a standard calling convention Secure Monitor
Calls in ARMv7 and ARMv8-A:
 Register us...
17
S-EL1
Power State Coordination Interface
 Defines a standard interface for
making power management
requests across exc...
18
Challenge #3: Dealing with bugs
 Working around hardware errata involves firmware
 may require setting secure process...
19
Taking the Opportunity
 Reduce duplicated effort by standardizing on a single
implementation framework for EL3 softwar...
20
ARM Trusted Firmware
 Firmware on ARM SoCs
 Why now, why ARMv8-A?
 ARM Trusted Firmware overview
 Where are we now ...
21
ARM Trusted Firmware Architecture
EL3 Firmware - BL31
(Secure Monitor)
SMC Interface
Service Router
Other EL3 Interface...
22
EL3 Firmware - BL31
(Secure Monitor)
SMC Interface
Service Router
Other EL3 Interfaces Interrupt Handler
World Switcher...
23
ARM Trusted Firmware
 Firmware on ARM SoCs
 Why now, why ARMv8-A?
 ARM Trusted Firmware overview
 Where are we now ...
24
Firmware Availability
 Binary delivery in Sep’13 Linaro AArch64 OpenEmbedded release
 FVP Base models only (AEMv8 and...
25
ARM Trusted Firmware project
 The current release (v0.2) is an first implementation
 Limited functionality; not yet o...
26
ARM Trusted Firmware at LCU13
 Thursday 11am – 1pm, GT America 2
 Deep Dive into ARM Trusted Firmware
 Technical tou...
Upcoming SlideShare
Loading in...5
×

LCU13: An Introduction to ARM Trusted Firmware

4,710
-1

Published on

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

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,710
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
221
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

LCU13: An Introduction to ARM Trusted Firmware

  1. 1. 1 ARM Trusted Firmware for ARMv8-A LCU13 – 28th October 2013 Andrew Thoelke
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×