Implementing Secure Software Systems on ARMv8-M Microcontrollers

Transcription

1 Implementing Secure Software Systems on ARMv8-M Microcontrollers Chris Shore, ARM

2 TrustZone: A comprehensive security foundation Non-trusted Trusted Security separation with TrustZone Isolate trusted resources from non-trusted Reduce attack surface of key components Security throughout the system Software, CPU, interconnect, memory and peripherals Crypto Trusted software Trusted hardware Secure Secure system storage TRNG Trusted hardware Fortified security for entire device lifecycle

3 ARM TrustZone for ARMv8-M Security foundation in hardware 3 ARM 2016

4 TrustZone for ARMv8-A TrustZone for ARMv8-M NON-SECURE STATE SECURE STATE NON-SECURE STATE SECURE STATE Non-secure App Secure Apps Non-secure App Secure Apps Non-secure OS Secure OS Non-secure OS Secure OS Secure Monitor TrustZone for ARMv8-M Secure transitions handled by the processor to maintain embedded class latency

5 Bringing security to the smallest devices ARMv8-M architecture The ARM architecture for ARM Cortex-M processors Provides a security foundation with TrustZone New AMBA 5 AHB5 specification Extends the security foundation through the ultra-low power SoC

6 ARMv8-M: Taking embedded to the next level Security Taking TrustZone security to the smallest devices Bringing security within reach of all developers Productivity Making scalable software development even easier

7 ARMv8-M: Security in small, real-time embedded Optimised for small real-time processors Hardware based security state switch Fully programmable in C Transparent to the software developer Low, deterministic interrupt latency Transition via a standard function call Efficient every cycle counts No hypervisor code and processing overhead Easy to program easy to debug

8 ARMv8-M architecture variants Baseline and Mainline Baseline includes fundamentals Mainline adds optional Extensive 32-bit instruction set ~ 40% performance uplift over Baseline Integer digital signal processing (DSP) extension ~ 80 saturating arithmetic and SIMD operations Optional floating-point (FP) extension ~ 45 instructions, IEEE754 compatible single, and/or double precision floating-point operations Baseline Hardware divide, mutually exclusive access, cond. branch, imm. move Standard functionalities TrustZone Options Mainline Co-processor support Single Precision Floating Point DSP Enhanced functionalities Baseline TrustZone

9 ARMv8-M additional states Existing handler and thread modes mirrored with secure and non-secure states Secure and Non-Secure code run on a single CPU For efficient embedded implementation. Handler Mode Secure state for trusted code New Secure stack pointers for robust operation Addition of stack-limit checking. Dedicated resources for isolation between domains Separate memory protection units for Secure and Non-secure Private SysTick timer for each state. Secure side can configure target domain of interrupts. Non-secure Handler Mode Non-secure Thread Mode ARMv8-M Thread Mode ARMv7-M Secure Handler Mode Secure Thread Mode

10 Security defined by address All transactions from core and debugger checked All addresses are either Secure or Nonsecure. Policing managed by Secure Attribution Unit (SAU) Internal SAU similar to MPU Supports use of external system-level definition E.g. based on flash blocks or per peripheral. Banked MPU configuration Independent memory protection per security state. Non-Secure MPU Request from CPU Security Attribution Unit (SAU) System Level Control Secure MPU Load/stores acquire NS attribute based on address Non-secure access attempts to Secure address = memory fault. Request to System

11 ARMv8-M programmer s model: Memory map 0xFFFFFFFF 0xF xE Non-secure state ROM tables System control and debug Non-secure memory view is identical with Cortex-M 0xA x x x x Off-chip peripherals Off-chip memory Peripherals RAM Flash Debug MPU SCB NVIC SysTick ITM/DWT/FBP Vector table for Non-secure handlers Branches to fixed memory locations access secure firmware Secure memory is invisible

12 ARMv8-M programmer s model: Memory map 0xFFFFFFFF 0xF xE xA x x x x Secure state ROM tables System control and debug Off-chip peripherals Off-chip memory Non-secure peripherals Secure peripherals Non-secure RAM Secure RAM Non-secure flash Secure flash Non-secure MPU alias Non-secure SCB alias Non-secure SysTick alias Debug SAU Secure MPU Secure SCB NVIC Secure SysTick ITM/DWT/FBP Vector table for secure handlers Secure memory view shows additional Flash, RAM, and peripherals Access to all regions is possible in secure state Regions can be configured in secure state using the SAU

13 High performance cross-domain calls Efficient microcontroller focussed implementation Security inferred from instruction address Secure memory considered to hold Secure code. Direct function calls across boundary High performance and high security Multiple entry points No need to go via monitor for transitions. Uses Secure Gateway instruction SG Only permitted in special Secure memory with Non-secure-callable attribute (NSC). Secure Secure handler mode Secure thread mode MSP_S MSPLIM_S PSP_S PSPLIM_S Calls Calls R0 R1 R13 R14 R15 Non secure Nonsecure handler mode Nonsecure thread mode MSP_NS MSPLIM_NS PSP_NS PSPLIM_N S

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

15 A simplified use case Composing a system with secure and non-secure projects Non-secure state Secure state User project User application Start Firmware project System start Non-secure projects cannot access secure resources Function calls Firmware Secure project can access everything I/O driver Function calls Function calls Communication stack Secure and non-secure projects may implement independent time scheduling

16 Retain the familiar programmers model Classic embedded design ARMv7-M Secure embedded design ARMv7-M Secure embedded design with TrustZone for ARMv8-M Untrusted Trusted Privileged Unprivileged Firmware RTOS Privileged Unprivileged Firmware RTOS Trusted resource manager and libs Privileged Unprivileged Firmware RTOS Trusted libraries Trusted resource manager and libs

17 Software development tools and software components 17 ARM 2016

18 Cross-domain function calls An assembly code level example Non-secure memory Secure memory (Non-secure callable) NonSecureFunc: BL SecureFunc Call SecureFunc: SG Memory <Non-secure code> Return to NS Enter Secure state <Secure code> BXNS lr Secure API Guard instruction (SG) polices entry point Placed at the start of function callable from non-secure code. Non-secure à secure branch faults if SG isn t at target address Can t branch into the middle of functions Can t call internal functions. Code on Non-secure side identical to existing code. Non-secure callable Non-secure SG Non-secure applications

19 Typical software generation flow Based on proposed update to ARM C Language Extension (ACLE) NSC contains branch veneers Automatically generated by tool chains (linker) main(). func1(); Linkage Symbol file / export library Non-secure callable SG B.W func1 SG B.W func2 SG B.W func3 Secure APIs func1:. func2:. func3:. attribute ((cmse_nonsecure_entry))

20 ARM C/C++ Compiler extensions for ARMv8-M C-Preprocessor macro ARM_FEATURE_CMSE indicates secure or non-secure mode Function attributes to support calls between secure and non-secure mode attribute ((cmse_nonsecure_entry)) Secure function that can be call by non-secure code attribute ((cmse_nonsecure_call)) Call to non-secure function from secure code Linker generates a export file with secure function entries int SecureFunc (int v) attribute ((cmse_nonsecure_entry)) { SecureFunc PROC SG return v+1; } ADDS BXNS ENDP r0,r0,#1 lr Non-secure user project Secure project Export of secure function entries

21 Writing secure code for execution in Secure State 21 ARM 2016

22 Potential attacks How to avoid software design flaws in secure applications Return from secure to non-secure state CPU Registers may still contain secret information Data pointers that obtain trusted data in non-secure state Non-secure code may provide incorrect pointers that address secure memory Asynchronous modifications to data processing in secure state Non-secure interrupts could change values that are being processed in secure state

23 Return from secure to non-secure state CPU registers may contain secret information Secure mode Secure Non-secure Non-secure mode R0 R1 R2 R3 R4 Returned R0 R1 R2 R3 R4 Read secret data left R12 R13 R14 R15 R12 R13 R14 R15

24 Return from secure to non-secure state Clear shared CPU register content to avoid information leakage Secure state Non-secure state decrypt: SG MOV r3, do the work MOV r3, #0 MSR APSR_flags, r3 BXNS lr cmse_nonsecure_entry attribute Clear R0-R3 when used Clear status flags ARM Compiler does not leak secure CPU register data to nonsecure mode SECURITY RISK Solved! ARM Compiler clears CPU registers that may contain secure data.

25 Obtain trusted data in non-secure code Call Secure function and provide a data pointer Non-secure Get data function Call Secure Access function Secure state Secure MPU SECURITY RISK! Is this a valid address to non-secure memory? If not, secure data may get corrupted. Secure RAM

26 Obtain trusted data in non-secure code Check for valid non-secure memory addresses ARMv8-M provides Test Target (TT) instruction to check memory attributes: Returns MPU and SAU configuration information ARM Compiler provides intrinsic functions for pointer validation: Secure state SECURITY RISK Solved! Verify pointer target addresses with ARM Compiler intrinsic functions.

27 Asynchronous modifications to data processing Non-secure interrupt functions may corrupt data currently processed Secure code should never trust non-secure data Non-secure memory may be modified by interrupt handlers High priority interrupt is non-secure state can interrupt secure code execution A debugger access restriction can still change non-secure memory Secure state SECURITY RISK! Non-secure data may be altered during secure code execution

28 Asynchronous modifications to data processing Ensure data processing in secure memory Copy non-secure data before validation Use volatile attribute to disable potential compiler access optimizations Secure state SECURITY RISK Solved! Object is volatile to avoid value propagation and value is validated.

29 Tools and components for software development Keil MDK IDE & debugger ARM Compiler 6 CMSIS v5 Fast Models ULINK debug adapters Cortex-M Prototyping System

30 ARM C/C++ Compiler extensions for ARMv8-M C-Preprocessor macro ARM_FEATURE_CMSE indicates secure or non-secure mode Function attributes to support calls between secure and non-secure mode attribute ((cmse_nonsecure_entry)) Secure function that can be call by non-secure code attribute ((cmse_nonsecure_call)) Call to non-secure function from secure code Linker generates a export file with secure function entries int SecureFunc (int v) attribute ((cmse_nonsecure_entry)) { SecureFunc PROC SG return v+1; } ADDS BXNS ENDP r0,r0,#1 lr Non-secure user project Secure project Export of secure function entries

31 API for interface to secure state: CMSIS* Non-secure state Application Secure state Library functions System monitor RTOS running in non-secure state: RTOS functionality available to non-secure and secure software Full-featured RTOS for non-secure application Supports function calls to secure state Callback events from secure state CMSIS provides common API Secure state provides data and firmware protection *Cortex Microcontroller System Interface Standard

32 CMSIS-CORE for secure mode projects startup_<compiler >.c CMSIS device startup system_<device >.c CMSIS system and clock configuration partitions.h Secure attributes and interrupt assignment Files relating to CMSIS-CORE including device specific files partitions.h provides initial setup for SAU and configures non-secure mode memory areas and interrupts <user >.c/c++ User application main() {... } <device >.h CMSIS device peripheral access CMSIS-CORE device files CMSIS-CORE header files generated from CMSIS-SVD User program

33 Summary ARMv8-M provides the architecture for the next generation of secure connected embedded devices Software and tools make it easy for developers to use secure mode CMSIS provides software building blocks for faster time to market of embedded applications that require security

34 Thank You!