SlideShare a Scribd company logo
1 of 26
Download to read offline
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
AppAppApp
AppAppApp
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
AppAppApp
AppAppApp
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
usrusr
Non-Secure Secure
AppAppApp
AppAppApp
OS OS
Hypervisor
AppAppApp
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
usrusr
Non-Secure Secure
AppAppApp
AppAppApp
OS OS
Hypervisor
AppAppApp
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
usrusr
Non-Secure Secure
AppAppApp
AppAppApp
OS OS
Hypervisor
AppAppApp
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
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
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
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
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
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
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
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

More Related Content

What's hot

LCU14 302- How to port OP-TEE to another platform
LCU14 302- How to port OP-TEE to another platformLCU14 302- How to port OP-TEE to another platform
LCU14 302- How to port OP-TEE to another platform
Linaro
 
HKG15-505: Power Management interactions with OP-TEE and Trusted Firmware
HKG15-505: Power Management interactions with OP-TEE and Trusted FirmwareHKG15-505: Power Management interactions with OP-TEE and Trusted Firmware
HKG15-505: Power Management interactions with OP-TEE and Trusted Firmware
Linaro
 
Embedded_Linux_Booting
Embedded_Linux_BootingEmbedded_Linux_Booting
Embedded_Linux_Booting
Rashila Rr
 
LCU14-103: How to create and run Trusted Applications on OP-TEE
LCU14-103: How to create and run Trusted Applications on OP-TEELCU14-103: How to create and run Trusted Applications on OP-TEE
LCU14-103: How to create and run Trusted Applications on OP-TEE
Linaro
 

What's hot (20)

Secure Boot on ARM systems – Building a complete Chain of Trust upon existing...
Secure Boot on ARM systems – Building a complete Chain of Trust upon existing...Secure Boot on ARM systems – Building a complete Chain of Trust upon existing...
Secure Boot on ARM systems – Building a complete Chain of Trust upon existing...
 
Q4.11: Introduction to eMMC
Q4.11: Introduction to eMMCQ4.11: Introduction to eMMC
Q4.11: Introduction to eMMC
 
Linux Internals - Part I
Linux Internals - Part ILinux Internals - Part I
Linux Internals - Part I
 
LCA14: LCA14-502: The way to a generic TrustZone® solution
LCA14: LCA14-502: The way to a generic TrustZone® solutionLCA14: LCA14-502: The way to a generic TrustZone® solution
LCA14: LCA14-502: The way to a generic TrustZone® solution
 
LCU14 302- How to port OP-TEE to another platform
LCU14 302- How to port OP-TEE to another platformLCU14 302- How to port OP-TEE to another platform
LCU14 302- How to port OP-TEE to another platform
 
Basic Linux Internals
Basic Linux InternalsBasic Linux Internals
Basic Linux Internals
 
U Boot or Universal Bootloader
U Boot or Universal BootloaderU Boot or Universal Bootloader
U Boot or Universal Bootloader
 
HKG15-505: Power Management interactions with OP-TEE and Trusted Firmware
HKG15-505: Power Management interactions with OP-TEE and Trusted FirmwareHKG15-505: Power Management interactions with OP-TEE and Trusted Firmware
HKG15-505: Power Management interactions with OP-TEE and Trusted Firmware
 
Linux Internals - Part II
Linux Internals - Part IILinux Internals - Part II
Linux Internals - Part II
 
BKK16-110 A Gentle Introduction to Trusted Execution and OP-TEE
BKK16-110 A Gentle Introduction to Trusted Execution and OP-TEEBKK16-110 A Gentle Introduction to Trusted Execution and OP-TEE
BKK16-110 A Gentle Introduction to Trusted Execution and OP-TEE
 
Linux-Internals-and-Networking
Linux-Internals-and-NetworkingLinux-Internals-and-Networking
Linux-Internals-and-Networking
 
Embedded Android : System Development - Part II (Linux device drivers)
Embedded Android : System Development - Part II (Linux device drivers)Embedded Android : System Development - Part II (Linux device drivers)
Embedded Android : System Development - Part II (Linux device drivers)
 
Embedded Linux on ARM
Embedded Linux on ARMEmbedded Linux on ARM
Embedded Linux on ARM
 
HKG15-311: OP-TEE for Beginners and Porting Review
HKG15-311: OP-TEE for Beginners and Porting ReviewHKG15-311: OP-TEE for Beginners and Porting Review
HKG15-311: OP-TEE for Beginners and Porting Review
 
Linux Kernel MMC Storage driver Overview
Linux Kernel MMC Storage driver OverviewLinux Kernel MMC Storage driver Overview
Linux Kernel MMC Storage driver Overview
 
HKG15-505: Power Management interactions with OP-TEE and Trusted Firmware
HKG15-505: Power Management interactions with OP-TEE and Trusted FirmwareHKG15-505: Power Management interactions with OP-TEE and Trusted Firmware
HKG15-505: Power Management interactions with OP-TEE and Trusted Firmware
 
Video Drivers
Video DriversVideo Drivers
Video Drivers
 
Linux Audio Drivers. ALSA
Linux Audio Drivers. ALSALinux Audio Drivers. ALSA
Linux Audio Drivers. ALSA
 
Embedded_Linux_Booting
Embedded_Linux_BootingEmbedded_Linux_Booting
Embedded_Linux_Booting
 
LCU14-103: How to create and run Trusted Applications on OP-TEE
LCU14-103: How to create and run Trusted Applications on OP-TEELCU14-103: How to create and run Trusted Applications on OP-TEE
LCU14-103: How to create and run Trusted Applications on OP-TEE
 

Similar to LCU13: An Introduction to ARM Trusted Firmware

08680982.pdfArchitectures for Security A comparative anal.docx
08680982.pdfArchitectures for Security A comparative anal.docx08680982.pdfArchitectures for Security A comparative anal.docx
08680982.pdfArchitectures for Security A comparative anal.docx
croftsshanon
 
HKG18-317 - Arm Server Ready Program
HKG18-317 - Arm Server Ready ProgramHKG18-317 - Arm Server Ready Program
HKG18-317 - Arm Server Ready Program
Linaro
 
Enhancement of ARINC 653 for Multi-core Hardware.pptx
Enhancement of ARINC 653 for Multi-core Hardware.pptxEnhancement of ARINC 653 for Multi-core Hardware.pptx
Enhancement of ARINC 653 for Multi-core Hardware.pptx
Abrar Hafiz
 
AMulti-coreSoftwareHardwareCo-DebugPlatform_Final
AMulti-coreSoftwareHardwareCo-DebugPlatform_FinalAMulti-coreSoftwareHardwareCo-DebugPlatform_Final
AMulti-coreSoftwareHardwareCo-DebugPlatform_Final
Alan Su
 

Similar to LCU13: An Introduction to ARM Trusted Firmware (20)

Slimline Open Firmware
Slimline Open FirmwareSlimline Open Firmware
Slimline Open Firmware
 
Building PoC ready ODM Platforms with Arm SystemReady v5.2.pdf
Building PoC ready ODM Platforms with Arm SystemReady v5.2.pdfBuilding PoC ready ODM Platforms with Arm SystemReady v5.2.pdf
Building PoC ready ODM Platforms with Arm SystemReady v5.2.pdf
 
LAS16-203: Platform security architecture for embedded devices
LAS16-203: Platform security architecture for embedded devicesLAS16-203: Platform security architecture for embedded devices
LAS16-203: Platform security architecture for embedded devices
 
Reliability, Availability, and Serviceability (RAS) on ARM64 status - SAN19-118
Reliability, Availability, and Serviceability (RAS) on ARM64 status - SAN19-118Reliability, Availability, and Serviceability (RAS) on ARM64 status - SAN19-118
Reliability, Availability, and Serviceability (RAS) on ARM64 status - SAN19-118
 
Provisioning the IoT
Provisioning the IoTProvisioning the IoT
Provisioning the IoT
 
ARM Processor Tutorial
ARM Processor Tutorial ARM Processor Tutorial
ARM Processor Tutorial
 
Q4.11: ARM Technology Update Plenary
Q4.11: ARM Technology Update PlenaryQ4.11: ARM Technology Update Plenary
Q4.11: ARM Technology Update Plenary
 
AAME ARM Techcon2013 003v02 Software Development
AAME ARM Techcon2013 003v02  Software DevelopmentAAME ARM Techcon2013 003v02  Software Development
AAME ARM Techcon2013 003v02 Software Development
 
Linux firmware for iRMC controller on Fujitsu Primergy servers
Linux firmware for iRMC controller on Fujitsu Primergy serversLinux firmware for iRMC controller on Fujitsu Primergy servers
Linux firmware for iRMC controller on Fujitsu Primergy servers
 
Q2.12: Power Management Across OSs
Q2.12: Power Management Across OSsQ2.12: Power Management Across OSs
Q2.12: Power Management Across OSs
 
Chapter_01_See_Program_Running.pptx
Chapter_01_See_Program_Running.pptxChapter_01_See_Program_Running.pptx
Chapter_01_See_Program_Running.pptx
 
08680982.pdfArchitectures for Security A comparative anal.docx
08680982.pdfArchitectures for Security A comparative anal.docx08680982.pdfArchitectures for Security A comparative anal.docx
08680982.pdfArchitectures for Security A comparative anal.docx
 
HKG18-317 - Arm Server Ready Program
HKG18-317 - Arm Server Ready ProgramHKG18-317 - Arm Server Ready Program
HKG18-317 - Arm Server Ready Program
 
Bkk16 309B Enterprise Firmware - The gold standard and how to get there
Bkk16 309B Enterprise Firmware - The gold standard and how to get thereBkk16 309B Enterprise Firmware - The gold standard and how to get there
Bkk16 309B Enterprise Firmware - The gold standard and how to get there
 
BKK16-309A Open Platform support in UEFI
BKK16-309A Open Platform support in UEFIBKK16-309A Open Platform support in UEFI
BKK16-309A Open Platform support in UEFI
 
Agnostic Device Drivers
Agnostic Device DriversAgnostic Device Drivers
Agnostic Device Drivers
 
Enhancement of ARINC 653 for Multi-core Hardware.pptx
Enhancement of ARINC 653 for Multi-core Hardware.pptxEnhancement of ARINC 653 for Multi-core Hardware.pptx
Enhancement of ARINC 653 for Multi-core Hardware.pptx
 
Hardware-assisted Isolated Execution Environment to run trusted OS and applic...
Hardware-assisted Isolated Execution Environment to run trusted OS and applic...Hardware-assisted Isolated Execution Environment to run trusted OS and applic...
Hardware-assisted Isolated Execution Environment to run trusted OS and applic...
 
Virtualization Support in ARMv8+
Virtualization Support in ARMv8+Virtualization Support in ARMv8+
Virtualization Support in ARMv8+
 
AMulti-coreSoftwareHardwareCo-DebugPlatform_Final
AMulti-coreSoftwareHardwareCo-DebugPlatform_FinalAMulti-coreSoftwareHardwareCo-DebugPlatform_Final
AMulti-coreSoftwareHardwareCo-DebugPlatform_Final
 

More from Linaro

Deep Learning Neural Network Acceleration at the Edge - Andrea Gallo
Deep Learning Neural Network Acceleration at the Edge - Andrea GalloDeep Learning Neural Network Acceleration at the Edge - Andrea Gallo
Deep Learning Neural Network Acceleration at the Edge - Andrea Gallo
Linaro
 
HPC network stack on ARM - Linaro HPC Workshop 2018
HPC network stack on ARM - Linaro HPC Workshop 2018HPC network stack on ARM - Linaro HPC Workshop 2018
HPC network stack on ARM - Linaro HPC Workshop 2018
Linaro
 
Intelligent Interconnect Architecture to Enable Next Generation HPC - Linaro ...
Intelligent Interconnect Architecture to Enable Next Generation HPC - Linaro ...Intelligent Interconnect Architecture to Enable Next Generation HPC - Linaro ...
Intelligent Interconnect Architecture to Enable Next Generation HPC - Linaro ...
Linaro
 
Andrew J Younge - Vanguard Astra - Petascale Arm Platform for U.S. DOE/ASC Su...
Andrew J Younge - Vanguard Astra - Petascale Arm Platform for U.S. DOE/ASC Su...Andrew J Younge - Vanguard Astra - Petascale Arm Platform for U.S. DOE/ASC Su...
Andrew J Younge - Vanguard Astra - Petascale Arm Platform for U.S. DOE/ASC Su...
Linaro
 
HKG18-501 - EAS on Common Kernel 4.14 and getting (much) closer to mainline
HKG18-501 - EAS on Common Kernel 4.14 and getting (much) closer to mainlineHKG18-501 - EAS on Common Kernel 4.14 and getting (much) closer to mainline
HKG18-501 - EAS on Common Kernel 4.14 and getting (much) closer to mainline
Linaro
 
HKG18-501 - EAS on Common Kernel 4.14 and getting (much) closer to mainline
HKG18-501 - EAS on Common Kernel 4.14 and getting (much) closer to mainlineHKG18-501 - EAS on Common Kernel 4.14 and getting (much) closer to mainline
HKG18-501 - EAS on Common Kernel 4.14 and getting (much) closer to mainline
Linaro
 
HKG18- 115 - Partitioning ARM Systems with the Jailhouse Hypervisor
HKG18- 115 - Partitioning ARM Systems with the Jailhouse HypervisorHKG18- 115 - Partitioning ARM Systems with the Jailhouse Hypervisor
HKG18- 115 - Partitioning ARM Systems with the Jailhouse Hypervisor
Linaro
 
HKG18-TR08 - Upstreaming SVE in QEMU
HKG18-TR08 - Upstreaming SVE in QEMUHKG18-TR08 - Upstreaming SVE in QEMU
HKG18-TR08 - Upstreaming SVE in QEMU
Linaro
 
HKG18-120 - Devicetree Schema Documentation and Validation
HKG18-120 - Devicetree Schema Documentation and Validation HKG18-120 - Devicetree Schema Documentation and Validation
HKG18-120 - Devicetree Schema Documentation and Validation
Linaro
 
HKG18-223 - Trusted FirmwareM: Trusted boot
HKG18-223 - Trusted FirmwareM: Trusted bootHKG18-223 - Trusted FirmwareM: Trusted boot
HKG18-223 - Trusted FirmwareM: Trusted boot
Linaro
 

More from Linaro (20)

Deep Learning Neural Network Acceleration at the Edge - Andrea Gallo
Deep Learning Neural Network Acceleration at the Edge - Andrea GalloDeep Learning Neural Network Acceleration at the Edge - Andrea Gallo
Deep Learning Neural Network Acceleration at the Edge - Andrea Gallo
 
Arm Architecture HPC Workshop Santa Clara 2018 - Kanta Vekaria
Arm Architecture HPC Workshop Santa Clara 2018 - Kanta VekariaArm Architecture HPC Workshop Santa Clara 2018 - Kanta Vekaria
Arm Architecture HPC Workshop Santa Clara 2018 - Kanta Vekaria
 
Huawei’s requirements for the ARM based HPC solution readiness - Joshua Mora
Huawei’s requirements for the ARM based HPC solution readiness - Joshua MoraHuawei’s requirements for the ARM based HPC solution readiness - Joshua Mora
Huawei’s requirements for the ARM based HPC solution readiness - Joshua Mora
 
Bud17 113: distribution ci using qemu and open qa
Bud17 113: distribution ci using qemu and open qaBud17 113: distribution ci using qemu and open qa
Bud17 113: distribution ci using qemu and open qa
 
OpenHPC Automation with Ansible - Renato Golin - Linaro Arm HPC Workshop 2018
OpenHPC Automation with Ansible - Renato Golin - Linaro Arm HPC Workshop 2018OpenHPC Automation with Ansible - Renato Golin - Linaro Arm HPC Workshop 2018
OpenHPC Automation with Ansible - Renato Golin - Linaro Arm HPC Workshop 2018
 
HPC network stack on ARM - Linaro HPC Workshop 2018
HPC network stack on ARM - Linaro HPC Workshop 2018HPC network stack on ARM - Linaro HPC Workshop 2018
HPC network stack on ARM - Linaro HPC Workshop 2018
 
It just keeps getting better - SUSE enablement for Arm - Linaro HPC Workshop ...
It just keeps getting better - SUSE enablement for Arm - Linaro HPC Workshop ...It just keeps getting better - SUSE enablement for Arm - Linaro HPC Workshop ...
It just keeps getting better - SUSE enablement for Arm - Linaro HPC Workshop ...
 
Intelligent Interconnect Architecture to Enable Next Generation HPC - Linaro ...
Intelligent Interconnect Architecture to Enable Next Generation HPC - Linaro ...Intelligent Interconnect Architecture to Enable Next Generation HPC - Linaro ...
Intelligent Interconnect Architecture to Enable Next Generation HPC - Linaro ...
 
Yutaka Ishikawa - Post-K and Arm HPC Ecosystem - Linaro Arm HPC Workshop Sant...
Yutaka Ishikawa - Post-K and Arm HPC Ecosystem - Linaro Arm HPC Workshop Sant...Yutaka Ishikawa - Post-K and Arm HPC Ecosystem - Linaro Arm HPC Workshop Sant...
Yutaka Ishikawa - Post-K and Arm HPC Ecosystem - Linaro Arm HPC Workshop Sant...
 
Andrew J Younge - Vanguard Astra - Petascale Arm Platform for U.S. DOE/ASC Su...
Andrew J Younge - Vanguard Astra - Petascale Arm Platform for U.S. DOE/ASC Su...Andrew J Younge - Vanguard Astra - Petascale Arm Platform for U.S. DOE/ASC Su...
Andrew J Younge - Vanguard Astra - Petascale Arm Platform for U.S. DOE/ASC Su...
 
HKG18-501 - EAS on Common Kernel 4.14 and getting (much) closer to mainline
HKG18-501 - EAS on Common Kernel 4.14 and getting (much) closer to mainlineHKG18-501 - EAS on Common Kernel 4.14 and getting (much) closer to mainline
HKG18-501 - EAS on Common Kernel 4.14 and getting (much) closer to mainline
 
HKG18-100K1 - George Grey: Opening Keynote
HKG18-100K1 - George Grey: Opening KeynoteHKG18-100K1 - George Grey: Opening Keynote
HKG18-100K1 - George Grey: Opening Keynote
 
HKG18-318 - OpenAMP Workshop
HKG18-318 - OpenAMP WorkshopHKG18-318 - OpenAMP Workshop
HKG18-318 - OpenAMP Workshop
 
HKG18-501 - EAS on Common Kernel 4.14 and getting (much) closer to mainline
HKG18-501 - EAS on Common Kernel 4.14 and getting (much) closer to mainlineHKG18-501 - EAS on Common Kernel 4.14 and getting (much) closer to mainline
HKG18-501 - EAS on Common Kernel 4.14 and getting (much) closer to mainline
 
HKG18-315 - Why the ecosystem is a wonderful thing, warts and all
HKG18-315 - Why the ecosystem is a wonderful thing, warts and allHKG18-315 - Why the ecosystem is a wonderful thing, warts and all
HKG18-315 - Why the ecosystem is a wonderful thing, warts and all
 
HKG18- 115 - Partitioning ARM Systems with the Jailhouse Hypervisor
HKG18- 115 - Partitioning ARM Systems with the Jailhouse HypervisorHKG18- 115 - Partitioning ARM Systems with the Jailhouse Hypervisor
HKG18- 115 - Partitioning ARM Systems with the Jailhouse Hypervisor
 
HKG18-TR08 - Upstreaming SVE in QEMU
HKG18-TR08 - Upstreaming SVE in QEMUHKG18-TR08 - Upstreaming SVE in QEMU
HKG18-TR08 - Upstreaming SVE in QEMU
 
HKG18-113- Secure Data Path work with i.MX8M
HKG18-113- Secure Data Path work with i.MX8MHKG18-113- Secure Data Path work with i.MX8M
HKG18-113- Secure Data Path work with i.MX8M
 
HKG18-120 - Devicetree Schema Documentation and Validation
HKG18-120 - Devicetree Schema Documentation and Validation HKG18-120 - Devicetree Schema Documentation and Validation
HKG18-120 - Devicetree Schema Documentation and Validation
 
HKG18-223 - Trusted FirmwareM: Trusted boot
HKG18-223 - Trusted FirmwareM: Trusted bootHKG18-223 - Trusted FirmwareM: Trusted boot
HKG18-223 - Trusted FirmwareM: Trusted boot
 

Recently uploaded

Breaking Down the Flutterwave Scandal What You Need to Know.pdf
Breaking Down the Flutterwave Scandal What You Need to Know.pdfBreaking Down the Flutterwave Scandal What You Need to Know.pdf
Breaking Down the Flutterwave Scandal What You Need to Know.pdf
UK Journal
 
Structuring Teams and Portfolios for Success
Structuring Teams and Portfolios for SuccessStructuring Teams and Portfolios for Success
Structuring Teams and Portfolios for Success
UXDXConf
 
Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...
Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...
Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...
panagenda
 
Harnessing Passkeys in the Battle Against AI-Powered Cyber Threats.pptx
Harnessing Passkeys in the Battle Against AI-Powered Cyber Threats.pptxHarnessing Passkeys in the Battle Against AI-Powered Cyber Threats.pptx
Harnessing Passkeys in the Battle Against AI-Powered Cyber Threats.pptx
FIDO Alliance
 

Recently uploaded (20)

Oauth 2.0 Introduction and Flows with MuleSoft
Oauth 2.0 Introduction and Flows with MuleSoftOauth 2.0 Introduction and Flows with MuleSoft
Oauth 2.0 Introduction and Flows with MuleSoft
 
WebAssembly is Key to Better LLM Performance
WebAssembly is Key to Better LLM PerformanceWebAssembly is Key to Better LLM Performance
WebAssembly is Key to Better LLM Performance
 
Breaking Down the Flutterwave Scandal What You Need to Know.pdf
Breaking Down the Flutterwave Scandal What You Need to Know.pdfBreaking Down the Flutterwave Scandal What You Need to Know.pdf
Breaking Down the Flutterwave Scandal What You Need to Know.pdf
 
Extensible Python: Robustness through Addition - PyCon 2024
Extensible Python: Robustness through Addition - PyCon 2024Extensible Python: Robustness through Addition - PyCon 2024
Extensible Python: Robustness through Addition - PyCon 2024
 
WebRTC and SIP not just audio and video @ OpenSIPS 2024
WebRTC and SIP not just audio and video @ OpenSIPS 2024WebRTC and SIP not just audio and video @ OpenSIPS 2024
WebRTC and SIP not just audio and video @ OpenSIPS 2024
 
Easier, Faster, and More Powerful – Notes Document Properties Reimagined
Easier, Faster, and More Powerful – Notes Document Properties ReimaginedEasier, Faster, and More Powerful – Notes Document Properties Reimagined
Easier, Faster, and More Powerful – Notes Document Properties Reimagined
 
Portal Kombat : extension du réseau de propagande russe
Portal Kombat : extension du réseau de propagande russePortal Kombat : extension du réseau de propagande russe
Portal Kombat : extension du réseau de propagande russe
 
Structuring Teams and Portfolios for Success
Structuring Teams and Portfolios for SuccessStructuring Teams and Portfolios for Success
Structuring Teams and Portfolios for Success
 
The Metaverse: Are We There Yet?
The  Metaverse:    Are   We  There  Yet?The  Metaverse:    Are   We  There  Yet?
The Metaverse: Are We There Yet?
 
The Value of Certifying Products for FDO _ Paul at FIDO Alliance.pdf
The Value of Certifying Products for FDO _ Paul at FIDO Alliance.pdfThe Value of Certifying Products for FDO _ Paul at FIDO Alliance.pdf
The Value of Certifying Products for FDO _ Paul at FIDO Alliance.pdf
 
1111 ChatGPT Prompts PDF Free Download - Prompts for ChatGPT
1111 ChatGPT Prompts PDF Free Download - Prompts for ChatGPT1111 ChatGPT Prompts PDF Free Download - Prompts for ChatGPT
1111 ChatGPT Prompts PDF Free Download - Prompts for ChatGPT
 
Simplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdf
Simplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdfSimplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdf
Simplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdf
 
How Red Hat Uses FDO in Device Lifecycle _ Costin and Vitaliy at Red Hat.pdf
How Red Hat Uses FDO in Device Lifecycle _ Costin and Vitaliy at Red Hat.pdfHow Red Hat Uses FDO in Device Lifecycle _ Costin and Vitaliy at Red Hat.pdf
How Red Hat Uses FDO in Device Lifecycle _ Costin and Vitaliy at Red Hat.pdf
 
Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...
Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...
Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...
 
Microsoft CSP Briefing Pre-Engagement - Questionnaire
Microsoft CSP Briefing Pre-Engagement - QuestionnaireMicrosoft CSP Briefing Pre-Engagement - Questionnaire
Microsoft CSP Briefing Pre-Engagement - Questionnaire
 
ADP Passwordless Journey Case Study.pptx
ADP Passwordless Journey Case Study.pptxADP Passwordless Journey Case Study.pptx
ADP Passwordless Journey Case Study.pptx
 
Using IESVE for Room Loads Analysis - UK & Ireland
Using IESVE for Room Loads Analysis - UK & IrelandUsing IESVE for Room Loads Analysis - UK & Ireland
Using IESVE for Room Loads Analysis - UK & Ireland
 
Harnessing Passkeys in the Battle Against AI-Powered Cyber Threats.pptx
Harnessing Passkeys in the Battle Against AI-Powered Cyber Threats.pptxHarnessing Passkeys in the Battle Against AI-Powered Cyber Threats.pptx
Harnessing Passkeys in the Battle Against AI-Powered Cyber Threats.pptx
 
Collecting & Temporal Analysis of Behavioral Web Data - Tales From The Inside
Collecting & Temporal Analysis of Behavioral Web Data - Tales From The InsideCollecting & Temporal Analysis of Behavioral Web Data - Tales From The Inside
Collecting & Temporal Analysis of Behavioral Web Data - Tales From The Inside
 
Event-Driven Architecture Masterclass: Challenges in Stream Processing
Event-Driven Architecture Masterclass: Challenges in Stream ProcessingEvent-Driven Architecture Masterclass: Challenges in Stream Processing
Event-Driven Architecture Masterclass: Challenges in Stream Processing
 

LCU13: An Introduction to ARM Trusted Firmware

  • 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