LCA14: LCA14-502: The way to a generic TrustZone® solution
Upcoming SlideShare
Loading in...5
×
 

LCA14: LCA14-502: The way to a generic TrustZone® solution

on

  • 783 views

Resource: LCA14

Resource: LCA14
Name: LCA14-502: The way to a generic TrustZone® solution
Date: 07-03-2014
Speaker: Joakim Bech

Statistics

Views

Total Views
783
Views on SlideShare
782
Embed Views
1

Actions

Likes
1
Downloads
28
Comments
0

1 Embed 1

http://www.slideee.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

LCA14: LCA14-502: The way to a generic TrustZone® solution LCA14: LCA14-502: The way to a generic TrustZone® solution Presentation Transcript

  • Fri-7-Mar, 10:05am, Joakim Bech LCA14-502: The Way To a Generic TrustZone® Solution
  • • Background • Where are Linaro right now? • Normal world • Linux kernel TEE device driver • Secure monitor • Trusted OS • Open Discussion • GlobalPlatform vs other API’s • Linux kernel TEE device driver • Trusted OS Agenda
  • • Does everyone know what a TEE is? • Why are Linaro involved in a TEE solution? • A number of organisations and companies wants a full open source TEE • Limited availability of open source reference software • Linaro and the members implements and tests ARM’s best practice • How will Linaro contribute? • Upstream to available open source TEE solutions • What do we want to achieve? • Prevent fragmentation • Be part of creating an open source TEE • Share development between stakeholders • Upstream everything • Interchangeable TEE components! Both open source and commercial! • Provide a good reference implementation Background
  • • Client library exposing standard APIs to secure services (GlobalPlatform or other) • Entrance point to the secure services • Calls a device driver in Linux kernel (IOCTL) • Can be configured to talk direct with the Trusted OS (boot scenario) • Serving the Trusted OS with file system access (RPC) • Loads Trusted Applications (TA’s) from filesystem Normal World - User Space
  • • Transport layer for data between normal world user space and the Trusted OS • IOCTL interface to user space clients • Secure Monitor Calls (SMC) to secure world • SMC Calling Convention • Handles scheduling (both normal and secure world) • Allocates memory for Trusted Applications • Will use dma_buf so that any allocator can be easily plugged: • HWMEM (ST-Ericsson memory allocator) • BPA2 (STMicroelectronics) • kmalloc doesn’t work, memory too fragmented • CMA (Contiguous Memory Allocator) Normal World - Linux Kernel
  • • ARMv8: ARM Trusted Firmware will include a Secure Monitor for switching between secure and non-secure world • ARMv8: Trusted Firmware is the reference but need to be extended with a Trusted OS Dispatcher Secure Monitor • ARMv7: we will have a Secure Monitor with a similar Trusted OS Dispatcher • ARMv7: PSCI in the Secure Monitor is currently out of scope
  • • Footprint, sizes (might be less soon) • How many files? • In total: ~500 c-files, ~250 h-files, ~20 assembler files • The core : 78 c-files, ~86 h-files, 18 assembler files • How many lines of code? • In total: ~160 000 • The core: ~40 000 • Memory: Core ~72kb, other ~110kb (crypto, big number, user TEE etc) • Exposing GlobalPlatform, Internal API • Crypto API • Hashes, Ciphers, RNG, Signatures, Key Exchange • Secure Storage • Store file on Linux file system using RPC mechanism • Store any file, but typically keys, signatures and other sensitive assets • Secure Time • Arithmetical API Trusted OS
  • • OS features • Demand paging • The TEE-Core and kernel TA’s fits on-chip RAM and runs in secure privileged mode • User TA’s run in DDR in secure user mode • Signed TEE-Core / TAs • Signature tools out-of scope of the Working Group (?) • Too customer specific • TEE source code will contain handles to check signed TAs • It is responsibility of TEE-core to authenticate the TAs • It is the boot responsibility to authenticate TEE-Core • Extensions: • Static TA: possibility to implement TAs included in the Core in order to extend TEE-Core capabilities (setting memory firewalls,...) Trusted OS cont.
  • Discussion - GlobalPlatform vs other API’s • GP have strong support, backed by several companies • GP lacks kernel interface, both from normal world (IOCTL) and towards the monitor • What other interfaces / APIs exists? STANDARD?
  • Discussion - TEE driver in Linux Kernel • No driver in vanilla kernel • - ST’s driver [GP] - MobiCore [Trustonic] [GP] - OTE Tegra [NVIDIA] [Non GP] - SierraTEE [GP] • How to merge and prevent fragmentation? • SMC Calling Convention should be followed
  • Discussion - Trusted OS • Questions? Ideas? • Scheduling? Pros, cons having it driven by normal world? • FIQ / IRQ handling? Where to catch interrupts? • Hardware interfaces? Maybe want to leverage crypto accelerator? Possible? • Side channel attacks? • Performance considerations? • License used? • Simulator / Emulator?
  • More about Linaro Connect: http://connect.linaro.org More about Linaro: http://www.linaro.org/about/ More about Linaro engineering: http://www.linaro.org/engineering/ Linaro members: www.linaro.org/members
  • Backup slides • The following slides are not supposed to be used during the presentation, but it might be that we want to show them during the discussions.
  • IRQ handling
  • FIQ handling
  • SMC handling