software development in ar mv8 m architecture - yiu

Title 44pt sentence case

Affiliations 24pt sentence case

20pt sentence case

© ARM 2017

Software development in ARMv8-M architecture

Joseph Yiu

Embedded World 2017

Senior embedded technology manager

14 March 2017

© ARM 2017 2


Bullets 24pt sentence case

bullets 20pt sentence case

Introducing ARM Cortex-M23 and Cortex-M33

ARMv6-M architectureFor ultra low-power and area-constrained designs

ARMv7-M architectureFor high performance and main stream products

Cortex-M23

TrustZone in smallest area, lowest power

Cortex-M33

Flexibility, control & DSP with TrustZone

TrustZone

Baseline sub-profile

Mainline sub-profile

ARMv8-M Architecture

© ARM 2017 3




ARMv8-M sub-profiles§ ARMv8-M Baseline:

§ Lowest-cost, smallest ARMv8-M implementations§ Instruction set enhancements over ARMv6-M§ System features enhancements

§ ARMv8-M Mainline:§ For general-purpose and feature rich

microcontroller products§ Highly scalable

Scalable architecture

Similar to ARMv6-M / ARMv7-M§ 32-bit architecture, architectural memory map§ Nested Vectored Interrupt Controller (NVIC)§ Architecturally defined sleep modes

Mainline

Baseline

ARMv6-M functionalities

Instruction set enhancements

TrustZone

Baseline functionalities

Additional instructions & functionalities

Enhanced debug and trace

DSP extension

Floating point extension

Coprocessor support

TrustZone

Options

Enhanced MPU

© ARM 2016 4

Text 54pt sentence case Thanks for reading

For more information on TrustZone for ARMv8-M visit arm.com

Sign-up for the latest news and information from ARM

© ARM 2017 5




Cortex-M23 – TrustZone in the smallest footprint

§ Most energy efficient ARMv8-M addressing:§ Security (TrustZone, stack limit feature)§ Ultra low-power designs§ High flexibility: many system features configurable

§ Two-stage pipeline with von Neumann bus architecture§ 0.98 DMIPS/MHz, 2.5 CoreMark/MHz

§ Key features§ Instruction set enhancements§ Optional single-cycle I/O interface§ Up to 240 interrupts with WIC support§ Enhanced Memory Protection Units (MPU)§ Enhanced debug features

Find out in the “Efficient Next-generation Embedded ARM TrustZone with ARMv8-M Implementation” presentation14-March-2017, 12:00 – 12:30. Session 11 – Tim Menasveta, ARM

© ARM 2017 6




Cortex-M23 key enhancements over Cortex-M0+

§ TrustZone security & stack limit check§ Higher scalability in system designs

§ More interrupts§ Exclusive accesses for multi-core systems§ Configurable initial vector table address§ Configurable number of MPU regions

§ Enhanced debug capability§ Optional instruction trace solutions

§ ETM – unlimited real-time trace§ MTB – low cost, without extra pins

§ New breakpoint unit§ Up to 4 watchpoint comparators

MPU

NVIC (max 32 IRQs)

WIC

MTBNVIC

(max 240 IRQs)

Enhanced MPU

Memory exclusives

Stack limit checking

Divide & performance enhancement

Enhanced debugFast I/O

C11 support

‘XOM’ support

TrustZone

JTAG/serial wire

ETM

ARMv6-M ISA

Cortex-M0+ feature set

Cortex-M23

Cortex-M0+

New or updated for Cortex-M23

© ARM 2017 7




Cortex-M33: Security for diverse embedded markets

§ Highly efficient processor with TrustZone addressing:§ Security with TrustZone security extension§ Higher performance and powerful instruction set § High configurability

§ Three-stage pipeline with Harvard bus architecture§ 1.5 DMIPS/MHz, 3.86 CoreMark/MHz

§ Key features§ Up to 480 interrupts and WIC support§ Memory Protection Units (MPU)§ Co-processor interface and instructions§ Floating point unit (FPv5), C11 support§ Enhanced debug features

Find out in the “Efficient Next-generation Embedded ARM TrustZone with ARMv8-M Implementation” presentation14-March-2017, 12:00 – 12:30. Session 11 – Tim Menasveta, ARM

© ARM 2017 8




Cortex-M33 key enhancements over Cortex-M4

MPUNVIC (max 240 IRQs)

WIC

ETM

AHB Lite

Co-processor interfaceStack limit checking

FPUv4

Better configurability

TrustZone

ARMv7-MSerial wire / JTAG

Enhanced MPUNVIC (max 480 IRQs)

WIC

ETM, MTB

AHB5

FPUv5

Serial wire / JTAGARMv8-M Mainline (incl. C11)

Cortex-M4

Cortex-M33

SIMD/DSP SIMD/DSP

Enhancements in debug

New or updated for Cortex-M33

Low power optimizations

§ TrustZone security and stack limit check§ Higher performance§ Better configurability

§ Instruction set§ More interrupts§ Configurable number of MPU regions§ Configurable initial vector table address

§ Enhanced debug capability§ Optional instruction trace solutions

§ ETM – unlimited real-time trace§ MTB – low cost, without extra pins

§ New breakpoint unit

© ARM 2017 9




TrustZone for ARMv8-M

Protected environment(Secure world)

§ Secure software§ Secure boot§ Cryptography libraries§ Authentication§ RTOS support APIs / RTOS

§ Secure resources§ Secure storages§ Crypto accelerators, TRNG

Normal environment(Non-secure world)

§ Applications§ User applications§ RTOS§ Device drivers§ Protocol stacks

§ Normal resources§ General peripherals

R0

R1

R13

Secure Non-secure

R14

R15

MSPLIM_S

PSPLIM_S

MSPLIM_NS

PSPLIM_NS

MSP_S

PSP_S

MSP_NS

PSP_NS

Secure handler mode

Secure thread m

ode

Non-secure handler mode

Non-secure thread mode

Calls

Calls

Secure world can access Non-secure resources

© ARM 2017 10




TrustZone security use cases – IoT MCU

§ Application developers§ Create IoT applications using preloaded drivers and libraries

§ Faster time to market§ Does not require in depth knowledge on security§ Firmware update is protected

§ Freedom to create any code in Non-secure world§ Able to reuse most existing firmware and largest ecosystem

§ Microcontroller vendors§ Able to provide added value and differentiate§ Able to protect their assets

§ Firmware protection§ Debug authentication

Customer application

TrustZone

Crypto library

Crypto accelerators

Firmware update

TRNG

Secure boot

Drivers

Secure storages (ID,keys, certificates)

© ARM 2017 11




IoT end points deployment with TrustZone

Trusted environment (Secure) Normal applications(Non-secure)

RTOS

Flash programming

Authentication & Provisioning

Cryptography(library & HW)

Secure storage(certificates)

App App App

App Middleware

Secure IoTcloud services

Hardware

API

gat

eway

s

IoT servicesDevice management

Secure firmware update

Secure boot Health check

© ARM 2017 12






RTOS

Flash programming




App App App

App Middleware


Hardware




Attacker

API

gat

eway

s

© ARM 2017 13






RTOS

Flash programming




App App App

App Middleware


Hardware




Attacker

API

gat

eway

s

© ARM 2017 14






RTOS

Flash programming




App App App

App Middleware


Hardware




Attacker

API

gat

eway

s

%#!?*@!?Cannot reprogram flash memory

Cannot steal certificates/keysCannot clone device

Cannot stop Secure services

© ARM 2017 15






RTOS

Flash programming




App App App

App Middleware


Hardware




Attacker

API

gat

eway

s

%#!?*@!?Cannot reprogram flash memory

Cannot steal certificates/keysCannot clone device

Cannot stop Secure services

System health detected abnormal activities – trigger system recovery

© ARM 2017 16






Flash programming




App

App Middleware


Hardware




Attacker

API

gat

eway

s

Cannot take over the device LGo somewhere else

System recovered

RTOS

App App

© ARM 2016 17

Text 54pt sentence case Details

© ARM 2017 18




ARMv8-M software development concepts

§ Separation of Secure and Non-secure worlds§ Debug authentication concepts§ ARMv8-M impact on development tools§ ARMv8-M impact on RTOS (Real Time Operating Systems)§ ARM C Language Extension (ACLE)

§ Cortex-M Security Extensions (CMSE)§ Coprocessor support (Cortex-M33 processor)

§ Cortex Microcontroller Software Interface Standard (CMSIS) version 5§ E.g. CMSIS-CORE header files

§ Fault handling§ Security Considerations

© ARM 2017 19




Concepts of a simple design

§ Memory Space contains§ Secure spaces§ Non-secure spaces

§ Two vector tables placed for Secure and Non-secure code§ When running code in Secure memory

§ Processor is in Secure state§ Use Secure MPU for data accesses

§ When running code in Non-secure memory§ Processor is in Non-secure state§ Use Non-secure MPU for data accesses

§ Selection of MPU for instruction fetch based on instruction address Non-secure

program

Non-secure SRAM

Non-secure peripherals

Secure program

Secure SRAM

Secure peripherals

Peripherals

SRAM

CODE

© ARM 2017 20




Security defined by address

§ All addresses are either Secure or Non-secure

§ Policing managed by Secure Attribution Unit (SAU) § 0/4/8 programmable regions§ Implementation Defined Attribution Unit (IDAU) interface for

adding hardware based policing rules§ 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

§ Load/stores acquire NS attribute based on address§ Non-secure access attempts to Secure address = memory

fault

All transactions from core and debugger checked

Non-SecureMPU

SecureMPU

SecurityAttributionUnit (SAU)

SystemLevel

Control

Request from CPU

Request to System

SystemspecificIDAU

© ARM 2017 21




§ Non-secure project cannot access Secure resources

§ Secure project can access everything

§ Secure andNon-secure projects may implement independent time scheduling

A simplified use caseComposing a system from Secure and Non-secure projects

Firmware projectUser project

Non-secure state Secure state

System start

Firmware

Communicationstack

User application

I/O driver

Function calls

Start

Function calls

Function calls

© ARM 2017 22




Debug authentication concepts

§ Different debug permissions in life cycle§ Full access§ Non-secure access only§ Disable both

§ In some cases§ MCU software developers can program

Non-secure side only§ Non-secure software can call Secure APIs

§ If allow Non-secure debug only§ Debugger cannot access Secure memories§ Cannot halt in Secure state§ Cannot step into Secure APIs§ Cannot trace Secure operations

© ARM 2017 23




What TrustZone means to software developers?

§ Typically, applications run in Non-secure world§ Just like running in existing Cortex-M0+, Cortex-M3, Cortex-M4§ Secure memories could be locked down by silicon vendors

§ Secure boot, software libraries, etc

§ Application level: None or few software changes§ All previous instructions are supported§ Most bare metal applications should run as today§ New CMSIS-CORE files for new processors§ MPU programmer’s model changes§ Recompile for best performance§ RTOS updated§ Vendor specific software library features§ Debug tool update

© ARM 2017 24




Software development tools§ Compilers updates

§ New instructions§ ARM C Language Extension (ACLE) update

§ Cortex-M Security Extension (CMSE)§ Coprocessor support intrinsics

§ Debugger updates§ New registers§ Debug components – programmer’s model changes§ Debug authentication support§ Enhanced trace features

§ CMSIS 5§ CMSIS-CORE – new header files for new processors§ CMSIS-RTOS – ARMv8-M support, C++, OS features

Note: No change in JTAG/Serial Wire debug protocols

© ARM 2017 25




What TrustZone means to RTOS

§ MPU programmer’s model changed§ EXC_RETURN code extended§ Additional stacks and stack limit features

§ MPU programmer’s model changed§ EXC_RETURN code extended§ Stack limit checking§ TrustZone support via standardised APIs

in Secure world

RTOS running in Secure world RTOS running in Non-secure world

Securesoftware library

Secure statesNon-secure states

Non-secureThread

Non-secureThread

Non-securethreads

SecureRTOS

Secure softwarelibrary

Secure statesNon-secure states

Non-secureRTOS

Non-secureThread

Non-secureThread

Non-securethread

OS support API

© ARM 2017 26




Key concepts of Secure software development

§ Secure and Non-secure software are developed and compiled separately

§ Cortex-M Security Extension (CMSE) features in C compilers§ Part of the ARM C Language Extension (ACLE) - portable§ C macro “__ARM_FEATURE_CMSE” available for pre-processing when compiling secure

software (__ARM_FEATURE_CMSE equals 3)

§ To build software in Secure state§ #include <arm_cmse.h>§ Compile with Security extension enabled (e.g. add “–mcmse” option on ARM Compiler 6

“armclang”, same option “-mcmse” is available for gcc)

© ARM 2017 27



bullets 20pt sentence case§ NSC contains branch veneers

§ Automatically generated by tool chains (linker)

Based on proposed update to ARM C Language Extension (ACLE)Typical Secure software generation flow

main()….func1(); SG

B.W func1SGB.W func2SGB.W func3…

Non-secure callable

Secure APIs

func1:….

func2:….

func3:….

Symbol file / export library

Linkage

__attribute__((cmse_nonsecure_entry))

© ARM 2017 28




Functions to check address/objects in memory

§ Address range

§ Object

§ Flag bits

void *cmse_check_address_range(void *p, size_t size, int flags)

void *cmse_check_pointed_object(void *p, int flags)

(returns NULL on a failed check, and p on a successful check)

macro Value Descriptions

CMSE_MPU_UNPRIV 4 Set the T flag in TT instruction

CMSE_MPU_READWRITE 1 Check Read-Write permission

CMSE_MPU_READ 8 Check Read-ok permission

CMSE_AU_NONSECURE 2 Check if the permissions has the Secure field unset

CMSE_MPU_NONSECURE 16 Set A flag in the TT instruction

CMSE_NONSECURE 18 CMSE_MPU_NONSECURE | CMSE_AU_NONSECURE

© ARM 2017 29




Secure API and Non-secure function call-back

§ Non-secure software passes a function pointer of call-back function to Secure world

#include <arm_cmse.h>typedef void __attribute__((cmse_nonsecure_call)) nsfunc(void);void default_callback(void) { … }

// Declare function pointer *fp// fp can point to a secure function or a non-secure functionnsfunc *fp = (nsfunc *) default_callback; // secure function pointer

// This is a Secure API with function pointer as input parametervoid __attribute__((cmse_nonsecure_entry)) entry(nsfunc *callback) {

fp = cmse_nsfptr_create(callback); // non-secure function pointer}

void call_callback(void) {if (cmse_is_nsfptr(fp)) fp(); // non-secure function callelse ((void (*)(void)) fp)(); // normal function call

}

Secure API for passing Non-secure function pointer

Define function pointer as Non-secure

Call Non-secure call-back function

© ARM 2017 30




CMSIS-CORE (CMSIS version 5)

§ New file “partition_<device>.h” for Secure software§ Function void TZ_SAU_Setup(void), called by void SystemInit(void), configure:

§ Memory space§ SAU regions – Address space partitioning§ Other device specific configuration (e.g. memory protection controllers)

§ Interrupts / exceptions§ NVIC_ITNS[0..7] – Security domain of each interrupt§ AIRCR.BFHFNMINS – determines if BusFault, HardFault and NMI should be Non-secure§ AIRCR.PRIS – Interrupt priority configuration

§ System§ SCR.DEEPSLEEPS – determines if Non-secure world can control deep sleep§ AIRCR.SYSRESETREQS – determine if Non-secure world can trigger system reset§ FPU – Can be set to allow Secure data (this results in additional registers to be stacked)

© ARM 2017 31




Cortex-M33 co-processor interface§ “Faster” access to peripherals / hardware accelerators

§ No need to setup address in register§ Not affected by bus traffic§ Usages – fast I/O, crypto accelerators

§ Support up to 8 co-processors§ 32-bit and 64-bit operations

§ Read (32-bit or 64-bit) + Operations (MRC, MRRC)§ Write (32-bit or 64-bit) + Operations (MCR, MCRR)§ Operations (CDP)

§ TrustZone aware§ Each co-processor can be assigned as Secure or Non-secure§ Security attribute in interface for fine-grain control

Co-processor

AHB 5

Memory system

Cortex-M33

Co-processor interface

Peripherals

Optional AHB interface

© ARM 2017 32




ACLE defined instrinics for co-processorInstructions Intrinsic Function

MCRMCR2

void __arm_mcr(coproc, opc1, uint32_t value, CRn, CRm, opc2)void __arm_mcr2(coproc, opc1, uint32_t value, CRn, CRm, opc2)

MCRRMCRR2

void __arm_mcrr(coproc, opc1, uint64_t value, CRm)void __arm_mcrr2(coproc, opc1, uint64_t value, CRm)

MRCMRC2

uint32_t __arm_mrc(coproc, opc1, CRn, CRm, opc2)uint32_t __arm_mrc2(coproc, opc1, CRn, CRm, opc2)

MRRC MRRC2

uint64_t __arm_mrrc(coproc, opc1, CRm)uint64_t __arm_mrrc2(coproc, opc1, CRm)

CDPCDP2

void __arm_cdp(coproc, opc1, CRd, CRn, CRm, opc2)void __arm_cdp2(coproc, opc1, CRd, CRn, CRm, opc2)

unsigned int val;val = __arm_rsr("cp1:0:c0:c0:0");

unsigned int val;__arm_wsr("cp1:0:c0:c0:0“, val);

Read co-processor

Write co-processor

Examples:

© ARM 2017 33




Fault handling

§ New SecureFault exception (type #7) for ARMv8-M Mainline (Cortex-M33)§ Additional fault status register

§ Fault handling codes can be affected

§ Notes§ HardFault and BusFault defaulted to Secure state§ Non-secure software cannot analyze faults occurred in

Secure world§ Secure software can analyze faults from Secure and

Non-secure software

Non-secure ISRStart

EXC_RETURN.S==1?(bit 6)

Yes (S==1)Exception taken from

Secure stateProcessor is in Non-

secure state and cannot access

secure info – Exit.

Stack frame @PSP_NS

EXC_RETURN.SPSEL==1?(bit 2)

Y (SPSEL==1)

Stack frame @MSP_NS

N (SPSEL==0)

Stacked return address is located at stack frame + 24(0x18)

No (S==0)Exception taken from

Non-secure state

Determine stack frame location in Non-secure fault handler

© ARM 2017 34




Fault handling in Secure software

Determine stack frame location in Secure software

§ More routes of identifying stack pointer for stack frame

§ Stack frame could be extended (S àNS case)

Secure ISRStart

EXC_RETURN.S==1?(bit 6)

Yes (S==1)Exception taken from

Secure state

No (S==0)Exception taken from

Non-secure state

EXC_RETURN.Mode==1? (bit 3)

Yes (Mode==1)Exception taken from Secure Thread mode

No (SPSEL==0)Y (SPSEL==1)

No (Mode==0)Exception taken from

Secure Handler mode

Stack frame @MSP_S

Stack frame @PSP_S

EXC_RETURN.SPSEL ==1? (bit 2)

No (SPSEL==0)Y (SPSEL==1)

No (Mode==0)Exception taken from Non-secure Handler

mode

Stack frame @MSP_NS

Stack frame @PSP_NS

CONTROL_NS.SPSEL ==1? (bit 2)

EXC_RETURN.Mode==1? (bit 3)

Yes (Mode==1)Exception taken from Non-secure Thread

mode

EXC_RETURN.DCRS==1? (bit 5) Stacked return address is located

at stack frame + 64(0x40)Yes

No

Stacked return address is located at stack frame + 24(0x18)

© ARM 2017 35



bullets 20pt sentence case§ Validation of input parameters (including pointers)

§ Value checks§ Pointer checks using CMSE intrinsics

§ Non-secure addresses are considered volatile (a Non-secure ISR could change it)

Validation of input parametersSecurity software considerations

SecureNon-secure

*ptr_x

Secure_API

Struct_A

ptr_struct_A

X

A->ptr_x

Pointer in structure is being used in code execution

Pointer to structure pass to Secure API as an input parameter

© ARM 2017 36



bullets 20pt sentence case§ Validation of input parameters (including pointers)

§ Value checks§ Pointer checks using CMSE intrinsics

§ Non-secure addresses are considered volatile (a Non-secure ISR could change it)

Input data in Non-secure addresses should be copied to Secure world then validated

Validation of input parametersSecurity software considerations

SecureNon-secure

*ptr_x

Secure_API

Struct_A

ptr_struct_A

NS ISR

X’

A->ptr_x

X

A Non-secure interrupt service

routine (ISR) can change the pointer value

© ARM 2017 37



bullets 20pt sentence case§ Non-secure code

§ Should not be able to access Secure data via Secure APIs§ If Non-secure caller is unprivileged, should not be able to access Non-secure privileged data

Makes sure Secure APIs use address check functions with correct flags

Secure API should check if Non-secure caller has permission to operate on the dataSecurity software considerations

SecureNon-secure

Unprivileged

PrivilegedSecure_API

Non-secure caller

data X

Non-secure MPU

© ARM 2017 38



bullets 20pt sentence case§ Utilize stack limit check feature

§ Security initialization§ Only entry points should be marked with Non-secure Callable (NSC) attribute § Unused NSC space should be filled§ Do not mark uninitialized SRAM as NSC (initial value unpredictable)

Other areasSecurity software considerations

© ARM 2017 39




Summary

Existing software for ARMv6-M/v7-M might need updates§ Recompile for best performance§ CMSIS 5 (e.g. New header files in CMSIS-CORE)§ RTOS update (Changes in MPU, EXC_RETURN)§ Fault handlers

Toolchains updates§ Compiler – new instructions, and ACLE support: CMSE (Cortex-M Security Extension),

coprocessor§ Debugger – changes in debug components, enhancement in trace feature, debug

authentication

Secure software§ Development flow§ Security considerations

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

Thank You

Additional resources on ARMv8-M architecture, Cortex-M23 and Cortex-M33 processors - ARM Community:

https://community.arm.com/docs/DOC-10896Developer.arm.com

https://developer.arm.com/products/processors/cortex-m

For more details on ARM Cortex-M23 and Cortex-M33 processorsEfficient Next-generation Embedded ARM TrustZone with ARMv8-M Implementation 14-March-2017, 12:00 – 12:30. Session 11 – Tim Menasveta, ARM

© ARM 2017 41




Key concepts of Secure software development

§ Secure and Non-secure software are developed and compiled separately§ Secure and Non-secure software developers can use different header files§ Secure software developers can use multi-project workspace to develop and test the whole

system (Secure + Non-secure software)

§ Cortex-M Security Extension (CMSE) features in C compilers§ Part of the ARM C Language Extension (ACLE) - portable§ C macro “__ARM_FEATURE_CMSE” available for pre-processing when compiling secure

software (__ARM_FEATURE_CMSE equals 3)

§ To build software in Secure state§ #include <arm_cmse.h>§ Compile with Security extension enabled (e.g. add “–mcmse” option on ARM Compiler 6

“armclang”, same option “-mcmse” is available for gcc)

© ARM 2017 42




Pointer checking in CMSE

§ A number of built-in intrinsic are defined for TT instructions

§ Functions to check address/objects in memory

Function

cmse_address_info_t cmse_TT(void *p) TT instruction

cmse_address_info_t cmse_TT_fptr(p) TT instruction for function pointer type

cmse_address_info_t cmse_TTT(void *p) TTT instruction

cmse_address_info_t cmse_TTT_fptr(p) TTT instruction for function pointer type

cmse_address_info_t cmse_TTA(void *p) TTA instruction

cmse_address_info_t cmse_TTA_fptr(p) TTA instruction for function pointer type

cmse_address_info_t cmse_TTAT(void *p) TTAT instruction

cmse_address_info_t cmse_TTAT_fptr(p) TTAT instruction for function pointer type

For Secure software only

For Secure & Non-secure software

void *cmse_check_address_range(void *p, size_t size, int flags)

void *cmse_check_pointed_object(void *p, int flags)

© ARM 2017 43




Several security considerations

§ Basic considerations for writing Secure code§ Validation of input parameters (including pointers)§ Non-secure addresses are considered volatile (a Non-secure ISR could change it)

§ Data in Non-secure addresses should be copied to Secure world then validate§ Secure API should check if Non-secure caller has permission to operate on the data

§ If data is Secure – not allowed§ If caller is unprivileged – make sure address check function has correct flags

§ Utilize stack limit check feature

§ Security initialization§ Only entry points should be marked with Non-secure Callable (NSC) attribute (unused NSC

space should be filled)§ Do not mark uninitialized SRAM as NSC (initial value unpredictable)

software development in ar mv8 m architecture - yiu

Technology