The Next Steps in the Evolution of Embedded Processors

Transcription

1 The Next Steps in the Evolution of Embedded Processors Terry Kim Staff FAE, ARM Korea ARM Tech Forum Singapore July 12 th 2017

2 Cortex-M Processors Serving Connected Applications Energy grid Automotive Environmental Home automation Healthcare Enterprise Retail Smart city Wearables Farming Identity & tracking VR / AR Building automation Connected clothing Robotics Sensor Industrial IoT Smart lighting Smart watch Space 2

3 The Needs for Security in the connected devices Communication Protection Cryptography, authentication Data Protection Secret data (keys, personal information) Firmware Protection IP theft, reverse engineering Operation Protection Maintaining service and revenue 3 Anti-tamper Protection Related to all other protections

4 So, we will talk about the new architecture for the Smart Connected Era ARM TrustZone for the ARMv8-M Security regions Cross-domain function calls Gateway entry ARMv8-M based micro-architecture Cortex-M23 Cortex-M33 Central Station for all things TrustZone for ARMv8-M 4

5 ARM Cortex-M Processors and the ARM Architecture Architecture Instruction Set Programmer s Model Memory Model Exception Model Debug Architecture 5

6 Target: Security for all embedded applications Root of trust applications - IoT Crypto Trusted software Trusted hardware system storage TRNG* IP Protection Valuable firmware Trusted drivers Trusted hardware Untrusted Trusted Sandboxing Certified OS / functionality Trusted drivers Trusted hardware * True random number generator Standard, affordable Developer friendly Ecosystem friendly 6

7 TrustZone for ARMv8-M Separation and access control Isolate trusted software and resources Reduce attack surface of key components Trusted software Provision of security services Small, well-reviewed code Untrusted Trusted Trusted hardware Hardware assist for cryptography -access validation built into SoC TRNG* Hardware system Software storage Crypto 7 *True Random Number Generation

8 Part 1: TrustZone security defined by address All addresses are defined either or Non-secure Policing managed by Security Attribution Unit (SAU) Internal SAU similar to MPU Supports use of external system-level definition (IDAU*) Non-secure MPU Request from CPU Security Attribution Unit System level control MPU Banked MPU configuration Independent memory protection per security state Request to system 8 *Implementation defined attribution unit

9 Same address map, different access permissions Configured into and Non-secure regions Defines access control to all regions including peripherals and memory No change for developers on the Non-secure side 0xFFFFFFFF 0xE xA x x x x Cortex-M standard 4GB linear address map System region Device region RAM region Peripheral region SRAM region CODE region System components and debug Off-chip peripherals Off-chip memory Peripherals SRAM Program flash Example partition with TrustZone Various, CPU controlled Non secure Non secure Non secure Non secure Non secure 9

10 Security extends to the whole system IDAU ARMv8-M Processor IDAU TrustZone aware bus master IDAU Legacy bus master (Non-) Security wrapper Legacy bus master () Security wrapper IDAU regions Non-secure regions System IP AMBA 5 AHB5 interconnect 10 access only Boot loader Memory Protection Controller Flash (Page based partitioning) Memory Protection Controller SRAM (Watermark level based partitioning) System Security Controller Peripheral Protection Controller AHB Peripherals AHB5 to APB bridge Peripheral Protection Controller APB Peripherals

11 Part 2: Additional states and Non-secure code run on a single CPU For efficient, embedded implementation state for trusted code New stack pointers for robust operation Addition of stack-limit checking Non-secure handler mode Non-secure thread mode ARMv8-M handler mode thread mode Dedicated resources for isolation between domains Separate memory protection units for and Non-secure Private SysTick timer for each state side can configure target domain of interrupts Handler mode Thread mode ARMv7-M 11

12 High performance cross-domain calls Direct function calls across boundary High performance and high security Multiple entry points No need to go via monitor for transitions Uses Gateway (SG) instruction Only permitted in special memory with Non-secure callable (NSC) attribute Dedicated stack for each domain and privilege level 12

13 Cross-domain function calls An assembly code level example Non-secure memory NonFunc: BL Func <Non-secure code> memory (Non-secure callable) Func: SG < code> BXNS lr Gateway (SG) polices entry point Placed at the start of function callable from Non-secure code Non-secure branch faults if SG isn t at target address Branch into the middle of functions is not allowed Calling internal functions is not allowed Code on Non-secure side identical to existing code Call Return to NS Enter state Memory Non-secure callable Non-secure SG API Non-secure applications 13

14 Interrupt Handling in ARMv8-M Each interrupt can be assigned as or Non- SysTick (NS) Some system exceptions are banked e.g. SysTick timer is banked interrupts can be programmed to have higher priority than Non- IRQs IRQs SysTick (S) Priority NVIC Nested Vectored Interrupt Controller Processor core Same operation as in ARMv7-M in most cases (no extra latency) IRQs Non- IRQs or IRQs Non- IRQs 14

15 ARMv8-M Interrupt Security High-performance interrupt handling with register protection Subject to priority, can interrupt Non- and vice versa can boost priority of own interrupts Uses current stack pointer to preserve context Running Code Non- Interrupt Uses ARMv7-M exception stacking mechanism Hardware pushes selected registers Interrupt handlers programmable in C Non- interruption of code CPU pushes all registers and zeroes them Removes ability for Non- to snoop on register values Pop All Registers Switch to Return from Interrupt Push All Registers Zero All Registers Switch to Non- Run Non- Handler 15

16 The result: an efficient TrustZone security isolation Comprehensive, holistic protection across the entire processor and system Two worlds - one CPU Real-time transition* Simple to use Transparent to software developer Same programmers model Non-trusted view Non-trusted Trusted Trusted view Optimized for small embedded Hardware-enforced isolation No hypervisor code or memory overhead Deterministic, low-latency interrupts services Firmware firmware Data data Peripherals Memory CPU resources 16 * 2 cycles

17 Bringing TrustZone to the Cortex-M family Cortex-M7 Maximum performance, control and DSP 25Bn Total units shipped * TrustZone High performance Cortex-M3 Performance efficiency Cortex-M4 Mainstream control and DSP Cortex-M33 Flexibility, control and DSP Performance efficiency Cortex-M0 Lowest cost, low power Cortex-M0+ Highest energy efficiency Cortex-M23 Smallest area, lowest power Lowest power & area ARMv6-M ARMv7-M ARMv8-M *Data as of Dec

18 Cortex-M33: Security for diverse embedded markets 32-bit processor of choice Optimal balance between performance and power 20% greater performance than Cortex-M4 With TrustZone, same energy efficiency as Cortex-M4 Digital signal control Bring DSP to all developers FPU offering up to 10x performance over software Extensible compute Coprocessor interface for tightly-coupled acceleration Security foundation System-wide security with TrustZone technology Enhanced memory protection Easy to program Dedicated protection for both and Non-secure states Enhanced & secure debug Security-aware debug Simplified firmware development 18

19 Ever-expanding world s #1 embedded ecosystem Public silicon lead partners Public ecosystem lead partners 19

20 Summary Think system! TrustZone is proven Programmers model is preserved Tools are ready Issues are identified Happy coding! Central Station for all things TrustZone for ARMv8-M 20

21 The trademarks featured in this presentation are registered and/or unregistered trademarks of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. All rights reserved. All other marks featured may be trademarks of their respective owners. Copyright 2017 ARM Limited