SlideShare a Scribd company logo

Software development in ar mv8 m architecture - yiu

Arm, profile picture
Arm

This document provides information on ARMv8-M architecture and TrustZone security for microcontrollers. It introduces the Cortex-M23 and Cortex-M33 processors that implement the ARMv8-M architecture. It describes the ARMv8-M sub-profiles and highlights key features of the Cortex-M23 and Cortex-M33 such as enhanced debug capabilities and support for TrustZone security. The document also discusses software development concepts for the ARMv8-M architecture such as separation of secure and non-secure worlds and debug authentication. Finally, it outlines how TrustZone can provide security for Internet of Things applications and endpoints.

Technology
Related topics:
Insights on Software Development
1 of 43
Downloaded 68 times
1
2
3
4
5
6
7
Most read
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
©ARM 2017 Software development in ARMv8-M architecture JosephYiu Embedded World 2017 Senior embedded technology manager 14 March 2017
©ARM 20172 Introducing ARM Cortex-M23 and Cortex-M33 ARMv6-M architecture For ultra low-power and area-constrained designs ARMv7-M architecture For 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 20173 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 § NestedVectored 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 20164 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 20175 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” presentation 14-March-2017, 12:00 – 12:30. Session 11 – Tim Menasveta,ARM
©ARM 20176 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 MTB NVIC (max 240 IRQs) Enhanced MPU Memory exclusives Stack limit checking Divide & performance enhancement Enhanced debug Fast 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 20177 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” presentation 14-March-2017, 12:00 – 12:30. Session 11 – Tim Menasveta,ARM
©ARM 20178 Cortex-M33 key enhancements over Cortex-M4 MPU NVIC (max 240 IRQs) WIC ETM AHB Lite Co-processor interface Stack limit checking FPUv4 Better configurability TrustZone ARMv7-M Serial wire / JTAG Enhanced MPU NVIC (max 480 IRQs) WIC ETM, MTB AHB5 FPUv5 Serial wire / JTAG ARMv8-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 20179 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 201710 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 201711 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 IoT cloud services Hardware APIgateways IoT services Device management Secure firmware update Secure boot Health check
©ARM 201712 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 IoT cloud services Hardware IoT services Device management Secure firmware update Secure boot Health check Attacker APIgateways
©ARM 201713 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 IoT cloud services Hardware IoT services Device management Secure firmware update Secure boot Health check Attacker APIgateways
©ARM 201714 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 IoT cloud services Hardware IoT services Device management Secure firmware update Secure boot Health check Attacker APIgateways %#!?*@!? Cannot reprogram flash memory Cannot steal certificates/keys Cannot clone device Cannot stop Secure services
©ARM 201715 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 IoT cloud services Hardware IoT services Device management Secure firmware update Secure boot Health check Attacker APIgateways %#!?*@!? Cannot reprogram flash memory Cannot steal certificates/keys Cannot clone device Cannot stop Secure services System health detected abnormal activities – trigger system recovery
©ARM 201716 IoT end points deployment with TrustZone Trusted environment (Secure) Normal applications (Non-secure) Flash programming Authentication & Provisioning Cryptography (library & HW) Secure storage (certificates) App App Middleware Secure IoT cloud services Hardware IoT services Device management Secure firmware update Secure boot Health check Attacker APIgateways Cannot take over the device L Go somewhere else System recovered RTOS App App
©ARM 201617 Details
©ARM 201718 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 201719 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 201720 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-Secure MPU Secure MPU Security Attribution Unit (SAU) System Level Control Request from CPU Request to System System specific IDAU
©ARM 201721 § Non-secure project cannot access Secure resources § Secure project can access everything § Secure and Non-secure projects may implement independent time scheduling A simplified use case Composing a system from Secure and Non-secure projects Firmware projectUser project Non-secure state Secure state System start Firmware Communication stack User application I/O driver Function calls Start Function calls Function calls
©ARM 201722 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 201723 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 201724 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 201725 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 Secure software library Secure statesNon-secure states Non-secure Thread Non-secure Thread Non-secure threads Secure RTOS Secure software library Secure statesNon-secure states Non-secure RTOS Non-secure Thread Non-secure Thread Non-secure thread OS support API
©ARM 201726 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 201727 § 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 func1 SG B.W func2 SG B.W func3 … Non-secure callable Secure APIs func1: …. func2: …. func3: …. Symbol file / export library Linkage __attribute__((cmse_nonsecure_entry))
©ARM 201728 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 theT 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 theTT instruction CMSE_NONSECURE 18 CMSE_MPU_NONSECURE | CMSE_AU_NONSECURE
©ARM 201729 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 function nsfunc *fp = (nsfunc *) default_callback; // secure function pointer // This is a Secure API with function pointer as input parameter void __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 call else ((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 201730 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 201731 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 201732 ACLE defined instrinics for co-processor Instructions Intrinsic Function MCR MCR2 void __arm_mcr(coproc, opc1, uint32_t value, CRn, CRm, opc2) void __arm_mcr2(coproc, opc1, uint32_t value, CRn, CRm, opc2) MCRR MCRR2 void __arm_mcrr(coproc, opc1, uint64_t value, CRm) void __arm_mcrr2(coproc, opc1, uint64_t value, CRm) MRC MRC2 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) CDP CDP2 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 201733 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 ISR Start EXC_RETURN.S==1? (bit 6) Yes (S==1) Exception taken from Secure state Processor 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 201734 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 ISR Start 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 201735 § 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 parameters Security 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 201736 § 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 parameters Security 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 201737 § 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 data Security software considerations SecureNon-secure Unprivileged Privileged Secure_API Non-secure caller data X Non-secure MPU
©ARM 201738 § 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 areas Security software considerations
©ARM 201739 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 ThankYou Additional resources on ARMv8-M architecture, Cortex-M23 and Cortex-M33 processors - ARM Community: https://community.arm.com/docs/DOC-10896 Developer.arm.com https://developer.arm.com/products/processors/cortex-m For more details on ARM Cortex-M23 and Cortex-M33 processors Efficient Next-generation Embedded ARMTrustZone with ARMv8-M Implementation 14-March-2017, 12:00 – 12:30. Session 11 – Tim Menasveta,ARM
©ARM 201741 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 201742 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 201743 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)

More Related Content

PPTX
Introduction to armv8 aarch64
Yi-Hsiu Hsu
 
PPT
CO by Rakesh Roshan
Anurag University Hyderabad
 
PDF
Zephyr-Overview-20230124.pdf
ibramax
 
PDF
Unit ii arm7 thumb
Dr. Pankaj Zope
 
PPTX
Instruction Set Architecture
Jaffer Haadi
 
PDF
Secure Boot on ARM systems – Building a complete Chain of Trust upon existing...
Linaro
 
DOCX
8051 data type and directives
SARITHA REDDY
 
PPTX
Arm DynamIQ: Intelligent Solutions Using Cluster Based Multiprocessing
Arm
 
Introduction to armv8 aarch64
Yi-Hsiu Hsu
 
CO by Rakesh Roshan
Anurag University Hyderabad
 
Zephyr-Overview-20230124.pdf
ibramax
 
Unit ii arm7 thumb
Dr. Pankaj Zope
 
Instruction Set Architecture
Jaffer Haadi
 
Secure Boot on ARM systems – Building a complete Chain of Trust upon existing...
Linaro
 
8051 data type and directives
SARITHA REDDY
 
Arm DynamIQ: Intelligent Solutions Using Cluster Based Multiprocessing
Arm
 

What's hot (20)

PPTX
PART-2 : Mastering RTOS FreeRTOS and STM32Fx with Debugging
FastBit Embedded Brain Academy
 
PPTX
Anr feature in lte
Lokendra Rathore
 
PPT
Assembly language
gaurav jain
 
PPTX
5G NR parameters
Sasi Reddy
 
PPT
Ericsson 2 g ran optimization complete training
sekit123
 
PPT
Parallel processing
Syed Zaid Irshad
 
PPT
Topic 1 Data Representation
ekul
 
PDF
Intel dpdk Tutorial
Saifuddin Kaijar
 
PPTX
Computer Registers.pptx
NancyBeaulah_R
 
PDF
Machine language
鍾誠 陳鍾誠
 
PDF
3 jump, loop and call instructions
Channabasappa Kudarihal
 
PDF
Andes RISC-V processor solutions
RISC-V International
 
PPTX
Regular Expression in Compiler design
Riazul Islam
 
PPTX
Parallel Programming
Uday Sharma
 
PPTX
GCC for ARMv8 Aarch64
Yi-Hsiu Hsu
 
PDF
LCA13: Power State Coordination Interface
Linaro
 
PPT
Lte network planning huawei technologies
Chaudary Imran
 
PPT
Memory Addressing
chauhankapil
 
PDF
Unit II arm 7 Instruction Set
Dr. Pankaj Zope
 
PDF
A Journey into Hexagon: Dissecting Qualcomm Basebands
Priyanka Aash
 
PART-2 : Mastering RTOS FreeRTOS and STM32Fx with Debugging
FastBit Embedded Brain Academy
 
Anr feature in lte
Lokendra Rathore
 
Assembly language
gaurav jain
 
5G NR parameters
Sasi Reddy
 
Ericsson 2 g ran optimization complete training
sekit123
 
Parallel processing
Syed Zaid Irshad
 
Topic 1 Data Representation
ekul
 
Intel dpdk Tutorial
Saifuddin Kaijar
 
Computer Registers.pptx
NancyBeaulah_R
 
Machine language
鍾誠 陳鍾誠
 
3 jump, loop and call instructions
Channabasappa Kudarihal
 
Andes RISC-V processor solutions
RISC-V International
 
Regular Expression in Compiler design
Riazul Islam
 
Parallel Programming
Uday Sharma
 
GCC for ARMv8 Aarch64
Yi-Hsiu Hsu
 
LCA13: Power State Coordination Interface
Linaro
 
Lte network planning huawei technologies
Chaudary Imran
 
Memory Addressing
chauhankapil
 
Unit II arm 7 Instruction Set
Dr. Pankaj Zope
 
A Journey into Hexagon: Dissecting Qualcomm Basebands
Priyanka Aash
 
Ad

Viewers also liked (16)

PDF
Optimizing ARM cortex a and cortex-m based heterogeneous multiprocessor syste...
Arm
 
PDF
A practical approach to securing embedded and io t platforms
Arm
 
PDF
So you think developing an SoC needs to be complex or expensive?
Arm
 
PDF
Developing functional safety systems with arm architecture solutions stroud
Arm
 
PDF
Efficient software development with heterogeneous devices
Arm
 
PDF
Sustainably Connecting a Global Community
Arm
 
PPTX
Introduction to memory order consume
Yi-Hsiu Hsu
 
PDF
A Guide to SlideShare Analytics - Excerpts from Hubspot's Step by Step Guide ...
SlideShare
 
PPTX
Yocto Project introduction
Yi-Hsiu Hsu
 
PDF
Theory of Computation Lecture Notes
FellowBuddy.com
 
PDF
SR-IOV: The Key Enabling Technology for Fully Virtualized HPC Clusters
Glenn K. Lockwood
 
PPTX
Mergulhando no WP
Ricardo Braz
 
DOC
Eplc risk management_template
gguinle
 
PPT
高谷知佐子講演_THE MORNING AFTER ― DEALING WITH POST-SIGNING SURPRISES IN CROSS-BORD...
mhmjapan
 
ODP
Clean master
alberto mellado montes
 
PPTX
Shane Greenstein Future Assembly 11/17/2015
Adrienne Debigare
 
Optimizing ARM cortex a and cortex-m based heterogeneous multiprocessor syste...
Arm
 
A practical approach to securing embedded and io t platforms
Arm
 
So you think developing an SoC needs to be complex or expensive?
Arm
 
Developing functional safety systems with arm architecture solutions stroud
Arm
 
Efficient software development with heterogeneous devices
Arm
 
Sustainably Connecting a Global Community
Arm
 
Introduction to memory order consume
Yi-Hsiu Hsu
 
A Guide to SlideShare Analytics - Excerpts from Hubspot's Step by Step Guide ...
SlideShare
 
Yocto Project introduction
Yi-Hsiu Hsu
 
Theory of Computation Lecture Notes
FellowBuddy.com
 
SR-IOV: The Key Enabling Technology for Fully Virtualized HPC Clusters
Glenn K. Lockwood
 
Mergulhando no WP
Ricardo Braz
 
Eplc risk management_template
gguinle
 
高谷知佐子講演_THE MORNING AFTER ― DEALING WITH POST-SIGNING SURPRISES IN CROSS-BORD...
mhmjapan
 
Clean master
alberto mellado montes
 
Shane Greenstein Future Assembly 11/17/2015
Adrienne Debigare
 
Ad

Similar to Software development in ar mv8 m architecture - yiu (20)

PDF
High end security for low-end microcontrollers
Milosch Meriac
 
PPTX
LAS16-203: Platform security architecture for embedded devices
Linaro
 
PPTX
Demystifying Security Root of Trust Approaches for IoT/Embedded - SFO17-304
Linaro
 
PDF
The importance of strong entropy for iot
Arm
 
PPTX
High Performance Object Storage in 30 Minutes with Supermicro and MinIO
Rebekah Rodriguez
 
PPTX
mbed Connect Asia 2016 Securing IoT with the ARM mbed ecosystem
armmbed
 
PPTX
Accelerating Innovation from Edge to Cloud
Rebekah Rodriguez
 
PDF
BKK16-200 Designing Security into low cost IO T Systems
Linaro
 
PPTX
RISC-V 30906 hex five multi_zone iot firmware
RISC-V International
 
PPTX
HiPEAC 2022_Marcelo Pasin presentation
VEDLIoT Project
 
PDF
s2000nano
Przemek Ostrowski
 
PDF
Review of QNX
Robert-Emmanuel Mayssat
 
PPTX
Balance, Flexibility, and Partnership: An ARM Approach to Future HPC Node Arc...
Eric Van Hensbergen
 
PPTX
Teksun Corporate Overview 2014
Teksun Microsys Pvt. Ltd.
 
PDF
How to Select Hardware for Internet of Things Systems?
Hannes Tschofenig
 
PDF
Performance of State-of-the-Art Cryptography on ARM-based Microprocessors
Hannes Tschofenig
 
PDF
Webinar: Synergy turbinado com o SSP1.4: criptografia elíptica, vídeo pela US...
Embarcados
 
PDF
Secure IOT Gateway
LF Events
 
PDF
[Webinar] Software: The Lifeblood of any Medical Device
ICS
 
PDF
BKK16-110 A Gentle Introduction to Trusted Execution and OP-TEE
Linaro
 
High end security for low-end microcontrollers
Milosch Meriac
 
LAS16-203: Platform security architecture for embedded devices
Linaro
 
Demystifying Security Root of Trust Approaches for IoT/Embedded - SFO17-304
Linaro
 
The importance of strong entropy for iot
Arm
 
High Performance Object Storage in 30 Minutes with Supermicro and MinIO
Rebekah Rodriguez
 
mbed Connect Asia 2016 Securing IoT with the ARM mbed ecosystem
armmbed
 
Accelerating Innovation from Edge to Cloud
Rebekah Rodriguez
 
BKK16-200 Designing Security into low cost IO T Systems
Linaro
 
RISC-V 30906 hex five multi_zone iot firmware
RISC-V International
 
HiPEAC 2022_Marcelo Pasin presentation
VEDLIoT Project
 
s2000nano
Przemek Ostrowski
 
Review of QNX
Robert-Emmanuel Mayssat
 
Balance, Flexibility, and Partnership: An ARM Approach to Future HPC Node Arc...
Eric Van Hensbergen
 
Teksun Corporate Overview 2014
Teksun Microsys Pvt. Ltd.
 
How to Select Hardware for Internet of Things Systems?
Hannes Tschofenig
 
Performance of State-of-the-Art Cryptography on ARM-based Microprocessors
Hannes Tschofenig
 
Webinar: Synergy turbinado com o SSP1.4: criptografia elíptica, vídeo pela US...
Embarcados
 
Secure IOT Gateway
LF Events
 
[Webinar] Software: The Lifeblood of any Medical Device
ICS
 
BKK16-110 A Gentle Introduction to Trusted Execution and OP-TEE
Linaro
 

Recently uploaded (20)

PDF
MIND Revenue Release Quarter 2 2025 Press Release
MIND CTI
 
PDF
How UI/UX Design Impacts User Retention in Mobile Apps.pdf
SynapseIndia
 
PPTX
MYSQL Presentation for SQL database connectivity
Swati270511
 
PPTX
20250228 LYD VKU AI Blended-Learning.pptx
DatVoNgoc
 
PDF
Reach Out and Touch Someone: Haptics and Empathic Computing
Mark Billinghurst
 
PPTX
Big Data Technologies - Introduction.pptx
kuthubussaman1
 
PDF
Advanced methodologies resolving dimensionality complications for autism neur...
IAESIJAI
 
PDF
Profit Center Accounting in SAP S/4HANA, S4F28 Col11
Libreria ERP
 
PPT
Teaching material agriculture food technology
LiaRayya
 
PDF
Machine learning based COVID-19 study performance prediction
IAESIJAI
 
PDF
Chapter 3 Spatial Domain Image Processing.pdf
Getnet Tigabie Askale -(GM)
 
PDF
Approach and Philosophy of On baking technology
30anthuong17
 
PDF
Architecting across the Boundaries of two Complex Domains - Healthcare & Tech...
Peter Tan
 
PDF
cuic standard and advanced reporting.pdf
SimoneTitaniumTomase
 
PPTX
Cloud computing and distributed systems.
kkkkkhan
 
PDF
Empathic Computing: Creating Shared Understanding
Mark Billinghurst
 
PPTX
ACSFv1EN-58255 AWS Academy Cloud Security Foundations.pptx
23bcla24
 
PPTX
KOM of Painting work and Equipment Insulation REV00 update 25-dec.pptx
muhammadmuneebnaeem7
 
PDF
Review of recent advances in non-invasive hemoglobin estimation
IAESIJAI
 
PDF
Optimiser vos workloads AI/ML sur Amazon EC2 et AWS Graviton
Julien SIMON
 
MIND Revenue Release Quarter 2 2025 Press Release
MIND CTI
 
How UI/UX Design Impacts User Retention in Mobile Apps.pdf
SynapseIndia
 
MYSQL Presentation for SQL database connectivity
Swati270511
 
20250228 LYD VKU AI Blended-Learning.pptx
DatVoNgoc
 
Reach Out and Touch Someone: Haptics and Empathic Computing
Mark Billinghurst
 
Big Data Technologies - Introduction.pptx
kuthubussaman1
 
Advanced methodologies resolving dimensionality complications for autism neur...
IAESIJAI
 
Profit Center Accounting in SAP S/4HANA, S4F28 Col11
Libreria ERP
 
Teaching material agriculture food technology
LiaRayya
 
Machine learning based COVID-19 study performance prediction
IAESIJAI
 
Chapter 3 Spatial Domain Image Processing.pdf
Getnet Tigabie Askale -(GM)
 
Approach and Philosophy of On baking technology
30anthuong17
 
Architecting across the Boundaries of two Complex Domains - Healthcare & Tech...
Peter Tan
 
cuic standard and advanced reporting.pdf
SimoneTitaniumTomase
 
Cloud computing and distributed systems.
kkkkkhan
 
Empathic Computing: Creating Shared Understanding
Mark Billinghurst
 
ACSFv1EN-58255 AWS Academy Cloud Security Foundations.pptx
23bcla24
 
KOM of Painting work and Equipment Insulation REV00 update 25-dec.pptx
muhammadmuneebnaeem7
 
Review of recent advances in non-invasive hemoglobin estimation
IAESIJAI
 
Optimiser vos workloads AI/ML sur Amazon EC2 et AWS Graviton
Julien SIMON
 

Software development in ar mv8 m architecture - yiu

  • 1. ©ARM 2017 Software development in ARMv8-M architecture JosephYiu Embedded World 2017 Senior embedded technology manager 14 March 2017
  • 2. ©ARM 20172 Introducing ARM Cortex-M23 and Cortex-M33 ARMv6-M architecture For ultra low-power and area-constrained designs ARMv7-M architecture For 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
  • 3. ©ARM 20173 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 § NestedVectored 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
  • 4. ©ARM 20164 Thanks for reading For more information on TrustZone for ARMv8-M visit arm.com Sign-up for the latest news and information from ARM
  • 5. ©ARM 20175 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” presentation 14-March-2017, 12:00 – 12:30. Session 11 – Tim Menasveta,ARM
  • 6. ©ARM 20176 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 MTB NVIC (max 240 IRQs) Enhanced MPU Memory exclusives Stack limit checking Divide & performance enhancement Enhanced debug Fast 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
  • 7. ©ARM 20177 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” presentation 14-March-2017, 12:00 – 12:30. Session 11 – Tim Menasveta,ARM
  • 8. ©ARM 20178 Cortex-M33 key enhancements over Cortex-M4 MPU NVIC (max 240 IRQs) WIC ETM AHB Lite Co-processor interface Stack limit checking FPUv4 Better configurability TrustZone ARMv7-M Serial wire / JTAG Enhanced MPU NVIC (max 480 IRQs) WIC ETM, MTB AHB5 FPUv5 Serial wire / JTAG ARMv8-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
  • 9. ©ARM 20179 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
  • 10. ©ARM 201710 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)
  • 11. ©ARM 201711 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 IoT cloud services Hardware APIgateways IoT services Device management Secure firmware update Secure boot Health check
  • 12. ©ARM 201712 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 IoT cloud services Hardware IoT services Device management Secure firmware update Secure boot Health check Attacker APIgateways
  • 13. ©ARM 201713 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 IoT cloud services Hardware IoT services Device management Secure firmware update Secure boot Health check Attacker APIgateways
  • 14. ©ARM 201714 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 IoT cloud services Hardware IoT services Device management Secure firmware update Secure boot Health check Attacker APIgateways %#!?*@!? Cannot reprogram flash memory Cannot steal certificates/keys Cannot clone device Cannot stop Secure services
  • 15. ©ARM 201715 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 IoT cloud services Hardware IoT services Device management Secure firmware update Secure boot Health check Attacker APIgateways %#!?*@!? Cannot reprogram flash memory Cannot steal certificates/keys Cannot clone device Cannot stop Secure services System health detected abnormal activities – trigger system recovery
  • 16. ©ARM 201716 IoT end points deployment with TrustZone Trusted environment (Secure) Normal applications (Non-secure) Flash programming Authentication & Provisioning Cryptography (library & HW) Secure storage (certificates) App App Middleware Secure IoT cloud services Hardware IoT services Device management Secure firmware update Secure boot Health check Attacker APIgateways Cannot take over the device L Go somewhere else System recovered RTOS App App
  • 18. ©ARM 201718 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
  • 19. ©ARM 201719 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
  • 20. ©ARM 201720 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-Secure MPU Secure MPU Security Attribution Unit (SAU) System Level Control Request from CPU Request to System System specific IDAU
  • 21. ©ARM 201721 § Non-secure project cannot access Secure resources § Secure project can access everything § Secure and Non-secure projects may implement independent time scheduling A simplified use case Composing a system from Secure and Non-secure projects Firmware projectUser project Non-secure state Secure state System start Firmware Communication stack User application I/O driver Function calls Start Function calls Function calls
  • 22. ©ARM 201722 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
  • 23. ©ARM 201723 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
  • 24. ©ARM 201724 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
  • 25. ©ARM 201725 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 Secure software library Secure statesNon-secure states Non-secure Thread Non-secure Thread Non-secure threads Secure RTOS Secure software library Secure statesNon-secure states Non-secure RTOS Non-secure Thread Non-secure Thread Non-secure thread OS support API
  • 26. ©ARM 201726 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)
  • 27. ©ARM 201727 § 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 func1 SG B.W func2 SG B.W func3 … Non-secure callable Secure APIs func1: …. func2: …. func3: …. Symbol file / export library Linkage __attribute__((cmse_nonsecure_entry))
  • 28. ©ARM 201728 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 theT 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 theTT instruction CMSE_NONSECURE 18 CMSE_MPU_NONSECURE | CMSE_AU_NONSECURE
  • 29. ©ARM 201729 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 function nsfunc *fp = (nsfunc *) default_callback; // secure function pointer // This is a Secure API with function pointer as input parameter void __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 call else ((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
  • 30. ©ARM 201730 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)
  • 31. ©ARM 201731 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
  • 32. ©ARM 201732 ACLE defined instrinics for co-processor Instructions Intrinsic Function MCR MCR2 void __arm_mcr(coproc, opc1, uint32_t value, CRn, CRm, opc2) void __arm_mcr2(coproc, opc1, uint32_t value, CRn, CRm, opc2) MCRR MCRR2 void __arm_mcrr(coproc, opc1, uint64_t value, CRm) void __arm_mcrr2(coproc, opc1, uint64_t value, CRm) MRC MRC2 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) CDP CDP2 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:
  • 33. ©ARM 201733 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 ISR Start EXC_RETURN.S==1? (bit 6) Yes (S==1) Exception taken from Secure state Processor 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
  • 34. ©ARM 201734 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 ISR Start 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)
  • 35. ©ARM 201735 § 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 parameters Security 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
  • 36. ©ARM 201736 § 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 parameters Security 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
  • 37. ©ARM 201737 § 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 data Security software considerations SecureNon-secure Unprivileged Privileged Secure_API Non-secure caller data X Non-secure MPU
  • 38. ©ARM 201738 § 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 areas Security software considerations
  • 39. ©ARM 201739 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
  • 40. 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 ThankYou Additional resources on ARMv8-M architecture, Cortex-M23 and Cortex-M33 processors - ARM Community: https://community.arm.com/docs/DOC-10896 Developer.arm.com https://developer.arm.com/products/processors/cortex-m For more details on ARM Cortex-M23 and Cortex-M33 processors Efficient Next-generation Embedded ARMTrustZone with ARMv8-M Implementation 14-March-2017, 12:00 – 12:30. Session 11 – Tim Menasveta,ARM
  • 41. ©ARM 201741 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)
  • 42. ©ARM 201742 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)
  • 43. ©ARM 201743 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)