1. ARM mbed OS: The End of the flat Operating System Security Model
Hannes Tschofenig
Internet of Things Business Unit
ARM
Hardware Enhancements for Secure Embedded Systems (HESES) Workshop
Prague 18th Jan. 2016

2. Explosive growth of IoT
Expected number of IoT devices shipped in 2020
1.6b
Smart
Home
1.8b
Smart City
0.6b
Industrial
1.1b
Other
60%
CAGR
40%
20%
50%
New ecosystems. New business models. New opportunities.
The Internet of Things is the next technology wave that is sweeping over our markets.
Along with it come huge new opportunities for new devices, significant growth, new business models and ecosystems.
Source: Gartner, 2015

3. IoT will be built by a new class of developer
Developers 8M
web 9M
mobile
600K
embedded
The number of embedded developers is quite small compared to the size of the developer commuities

4. Security Challenges at the same time…
See more:
IAB Plenary presentation:

5. Traditional Embedded Development vs. IoT
Historically closed systems
Very little code reuse or design commonality between systems
Very few developers have strong experience in creating secure systems
Need a platform with built-in security and strong guidance on best practices
History of engineering closed systems
Somewhat secure thanks to isolation (SW, communication and physical) and obscurity (low volume)
Very little code reuse and design commonality between systems
These “Embedded” norms can’t survive in a successful connected IoT world
When you add networking everything changes
Exposed systems connected to the internet
Managing high complexity in networking stacks requires code reuse and modern dev approach
MCUs need to become accessible to a larger audience of developers
Few developers have security experience
mbed IoT Device Platform is the best starting point

6. Internet Protocol to the Edge
To use the Web and the Internet to the best possible extend IoT devices need to support IP.
Modern 32-bit MCUs easily handle IP stacks (and Internet security as well)
Non-standard approaches are a risk
Particularly when it comes to rolling out your own, custom security mechanism.
Information Models
IPv4 | IPv6 | 6LoWPAN
UDP | TCP
DTLS | TLS
CoAP | HTTP
REST APIs
IoT Application
Device Management
Internet Security has been constantly evolving for decades
Opportunity to leverage this heritage for IoT end nodes
Key security mechanisms that must be used
Don’t underestimate the capabilities of low cost, long battery life end nodes
Not a good idea to reinvent the wheel (non-IP) for end nodes – easy to repeat past mistakes
Security is about the weakest link
Flaws in protocol and security architecture
Deployment mistakes and mismanagement

7. Continuous Integration
Connectivity
CoAP
HTTP
IPv6/UDP
MAC/PHY
management
Device
Firmware Update
Boot loader
Flash HAL
Channel
security
Auth
DTLS
Crypto
Algo
Sensing
Algorithms
Calibration
Device
Drivers
Device
security
Keys
Secure Storage
Secure Boot
Debug
Debug Comms
C Runtime
Boot
Component Management
Unit Testing
Version Control
Toolchain
Continuous Integration
Test Automation
Code Review
Build System
Tools
Key
Management
Device Management
Admin & Debug
Bootstrap
CoAP
HTTP
Persistent
connectivity
Load Balancing
Clustering
Device
Server
Complexity of today’s IoT device software.

8. A Typical IoT End Node Device
May have a long lifetime
May be physically inaccessible
Must be able to manage remotely
Suffers from various constraints
(may have) a long lifetime
(may be) physically inaccessible
If you want to be able to handle IoT devices generically you DO need to be able to cope with the case where devices are physically inaccessible. In particular the device generally has no physical UI (for config) or a button to trigger device reset. If you want to power cycle the thing you can't go find it and pull the battery out. If it gets infected with malware then you can't take the HDD our and reformat it. etc. etc
Even if a device is physically accessible then you don't want users to have to do that sort of thing and you don't want to pay field/installation engineers to go to each IoT end node and do these things.
remote management a must & remotely updatable/recoverable

9. Recap Increasing IoT deployment and projected volumes are huge
Innovation comes from a new class of developers (or at least from developers with a different skill set – and different expectations)
Complexity of software increases for Internet-connected devices
Security already a problem today
IoT devices have unique properties and constraints.

10. mbed Ecosystem Management Productivity Security Connectivity
So this is what we built: The ARM mbed IoT Device Platform
ARM and its Partners share a disruptive vision where the creation and deployment of commercial, standards-based Internet of Things devices is possible at scale.
Open source, free, device side software supporting comprehensive functionality for IoT end nodes. Tools to write; verify; manage; configure and deploy that software. Cloud services to make it easy to deploy web applications that connect to large scale device deployments. A supporting ecosystem of 3rd party hardware and services.
Our guiding principals:
Improve productivity when dealing with all this complexity
Security is critical! Some exiting systems have tried to add this as an afterthought. We have an obligation and responsibility to protect global infrastructure. We must address security. It must be architected from the very beginning
Connectivity – remove this as an obstacle to deployment. Made simple
Management – 10’s billions devices to manage. Need this to avoid immediate obsolescence and frustration
Efficiency is core to ARM. May devices will be battery powered.
Productivity
Security
Connectivity
Efficiency

11. mbed Device Server mbed OS mbed Ecosystem
Freemium model to enable startups
Application data and device management
Growth market access for cloud platforms and operators
mbed Ecosystem
Partners
Developers
Enabled Services
Enabled Products
mbed OS
Free for use on ARM architecture
Leading connectivity standards
Productivity, minimized costs
Built-in management
Security
ARM Cortex®-M
-based MCU 11

12. Community
Partnership
mbed.com
mbed Enabled
Workflow
Collaboration
Licensing
Testing
Continuous Integration
Tools
yotta
IDEs
greentea
Developer Services

13. Mbed OS is for Cortex-M Processors
Maximum Performance
Flexible Memory Cache
Single & Double Precision FP
Examples: Automotive,
High-end audio set
Digital Signal Control (DSC)/ Processor with DSP Accelerated SIMD Floating point (FP)
Example: Sensor fusion,
motor control
Performance & efficiency Feature rich connectivity
Example: Weables,
Activity trackers, Wifi receiver
Lowest power Outstanding energy efficiency
Example: Sensor node
Bluetooth Smart
Lowest cost Low power
Example: Touchscreen
Controller
Processors use the 32-bit RISC architecture 13

14. mbed OS: Architected Security from the Ground up
Lifecycle Security
mbed OS Secure Identity, Config and Update
Communication Security
mbed TLS
Secure Code Compartments
mbed OS uVisor on ARMv7-M MPU
Talking points:

15. mbed OS: Architected Security from the Ground up
Hardware Interfaces
mbed OS
uVisor
Drivers
Core
Schedulers
mbed OS API
Communication Management
Device Management
mbed TLS
mbed Client
IP Stack
BLE API
Event
Tasks
Energy
Device Drivers
CMSIS-Core
Application Code
Libraries
Debug Support
Lifecycle Security
Secure Drivers
ARMv6-M
ARMv7-M
ARM Cortex-M CPU
MCU
Radio
Sensor
Crypto
SW Crypto
Thread
WiFi
BLE
6LoWPAN
Thread API
Communication
Security
Lifecycle
Device

16. Traditional MCU Flat Security Model
Server
IoT devices include significant software complexity
With flat security all code/data lives in a shared address space
Bugs in any code can lead to a security flaw
Application Protocol
Application Protocol
BLE Stack
BLE Stack
SSL Library
SSL Library
Diagnose
Diagnose
WiFi Stack
WiFi Stack
Secure Storage
Secure Storage
Device Management
Device Management
Secure ID
Secure ID
Crypto Keys
Crypto Keys
Crypto API
Crypto API
RNG
Firmware Update
Firmware Update

17. Device Security: Secure Partitioning for MCUs
Server
Split memory into private critical and public uncritical
Small private footprint simplifies code analysis
Public code never sees keys/secrets
Vulnerabilities on public side can’t affect private side
Private side can verify integrity of the public side
Public code can’t write code directly to Flash
Private side can reliably recover device to clean state
Public
Private
Application Protocol
SSL Library
Diagnose
WiFi Stack
BLE Stack
Device Management
Secure Storage
Crypto Keys
Secure ID
Crypto API
Firmware Update
RNG
Hardware enforced partitioning of MCU resources:
Split security domains into private critical and public uncritical code
Keep footprint of private code small to enable exhaustive verification
Allow public code to operate on cryptographic secrets using defined private API’s but never allow access to raw keys
Attacker can compromise the public side without affecting private security
Private side can verify integrity of the public side
Firmware update fully secured. Publics code can’t write code directly to Flash
Private side can reliably recover device to a clean state
Why has this not been done before?
This approach is a relatively common technique in good security implementations. However, (as we will explain in the next slide) what is implemented in mbed OS is very different from what is currently available in embedded systems built on top of existing RTOS’s. We build on guarantees provided by the Cortex-M processor architecture which enable us to implement robust partitioning. This solution covers network attacks. If a local attacker gains access to debug features of an MPU via Lab attack then this security can be circumvented. [specific to this implementation]
A-Class TrustZone provides a generic, scalable solution that enables very complex & secure functionality with minimal SW overhead
With mbed OS security deployed on M-Class we strictly limit secure partitioning complexity to limit our overheads
This is not a generic M-Class security solution – it works here thanks to the way we’ve architected mbed OS
Although overheads are comparatively low we can’t provides guarantees (e.g. hard real time) that might be needed in some applications

18. The uVisor Design Principles
Exposed
Critical
Secure Storage
Crypto Keys
Secure ID
Firmware Update
Crypto API
PRNG
Application Protocol
TLS Library
Diagnose
WiFi Stack
BLE Stack
Device Management
Ease of use
Hardware-enforced security sandboxes
“Princle of Least Privilege”
Boxes are protected against each other and malicious code is contained
Per-box access control lists (ACL)
Restrict access to selected peripherals
Shared memories for box-box communication
Future Versions of mbed OS will separate critical components like firmware update or raw cryptographic keys functions to ensure bugs in one secure modules won’t affect other secure modules.

19. The uVisor Boot Process on the ARMv7-M Architecture
uVisor initialized first in boot process
Private stack and data sections
Private data sections in flash for storing secrets
Relocation of interrupts vector table into secure memory
Initialization of memory protection unit based on box ACL’s
Whitelist approach – only necessary peripherals are accessible to each box
Each box has private .bss data and stack sections
Continue boot unprivileged to initialize C/C++ libraries

20. The uVisor memory model
uVisor allocates protected per-box stacks and detects under-/overflows during operation
Main box memory accessible to all boxes
All remaining per-Box data sections are protected by default:
Secure Per-Box Context Memory
Shared data/peripherals with other boxes on demand
uVisor resolves ACLs during boot and identifies ACL collisions
uVisor code sections visible to everybody
Empty flash memory is made available to the system as configuration storage – write access only through configuration API

21. Enable uVisor and Share Peripherals Across Boxes
#include <uvisor-lib/uvisor-lib.h>
/* set uvisor mode (enable) */
UVISOR_SET_MODE(UVISOR_ENABLED);
enable uVisor – optionally with shared peripherals across boxes:
#include <uvisor-lib/uvisor-lib.h> /* create background ACLs for the main box */ static const UvBoxAclItem g_background_acl[] = { {UART0, sizeof(*UART0), UVISOR_TACL_PERIPHERAL}, {UART1, sizeof(*UART1), UVISOR_TACL_PERIPHERAL}, {PIT, sizeof(*PIT), UVISOR_TACL_PERIPHERAL}, }; /* set uvisor mode (enable) */ UVISOR_SET_MODE_ACL(UVISOR_ENABLED, g_background_acl);

22. Setting up Protected Sandboxes
/* create private box context */ typedef struct { uint8_t secret[SECRET_SIZE]; bool initialized; } BoxContext; /* create ACLs for the module */ static const UvBoxAclItem g_box_acl[] = { {RNG, sizeof(*RNG), UVISOR_TACL_PERIPHERAL}, /* a peripheral */ }; /*required stack size */ #define BOX_STACK_SIZE 0x100 /* configure secure box compartment */ UVISOR_BOX_CONFIG(my_box_name, g_box_acl, BOX_STACK_SIZE, BoxContext);

23. Recap Mbed OS offers Device security Communication security*
Lifecycle security*
Device security relies on the Memory Protection Unit (MPU), an optional hardware feature available with Cortex M processors**.
Mbed OS code available at
(*) Not discussed in this presentation.
(**) Cortex M0 and M1 do not offer an MPU.

24. Improving Device Security
Separation
Isolate trusted resources from non-trusted
Isolate non-trusted software
Reduce attack surface of key components
non-trusted
trusted
Trusted Software
Provision of security services
Small, well reviewed code
trusted software
Trusted Hardware
Hardware assist for cryptography
Secure access validation built into SoC
trusted hardware
crypto
secure system
secure
storage
TRNG

25. Bringing Security to the Smallest Devices
Today
mbed OS uVisor on ARMv7-M MPU
Tomorrow
ARMv8-M architecture
The ARM architecture for ARM Cortex-M processors
Provides a security foundation with TrustZone
Optimised for smart and connected embedded applications.
Optimized for cost and power sensitive MCU and mixed-signal devices, Internet of Things, connectivity, motor control, etc
(icon fest)

26. ARM Architecture Profiles
Application Profile ARMv8-A
32-bit and 64-bit
A32, T32 and A64 instruction sets
Virtual memory system
Supporting rich operating systems
Real-time Profile
ARMv8-R
32-bit
A32 and T32 instruction sets
Protected memory system
(optional virtual memory)
Optimized for real-time systems
Microcontroller Profile
ARMv8-M
32-bit
T32 / Thumb® instruction set only
Protected memory system
Optimized for microcontroller applications
With the launch of ARMv8-M, ARM has now completed all three profiles for the 8th generation of the ARM architecure.
Just to remind you, these are the application profile with architecure ARMv8-A, like the Cortex-A57, A72 and A35 processors used in mobile devices and servers.
Then there is the Real-time profile with the ARMv8-R architecture that is targetted at real-time applications, for example in cars, but also in hard disk controllers.
Finally, the microcontroller profile with the ARMv8-M architecure is designed for resource constrained microcontroller applications.

27. 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
Efficiency
Mainline: co-pro allows for system design with optimal energy trade-off
Main line and base line: more configurable options for, again, energy optimal design
V8-M supports AHB5 with Q channel information allowing for, again, system design for optimal energy usage.
How can energy efficiency not be one of the main pillars of a new Cortex-M architecture?
Security
The robustness of software-managed security is directly proportional to the expertise of the development team. As a result, today, companies compete for the very few best in class security software developers. By moving security down into the hardware architecture, TrustZone reduces the complexity further up the stack thus making security designs accessible to a larger pool of software developers. The number of market segments served is directly proportional to the number of developers available.  

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

29. ARMv8-M: Increased Software Productivity
Enhanced debug
Easier, standardised device protection
Improved scalability
Improved trace
TrustZone security
Continuum across product family
More flexible breakpoints/watchpoints
Simplified MPU
Easier Code Protection
TrustZone => cross-vendors standard allowing easy reuse and migration
Improved MPU programmer’s model
Read only memory on baseline profile
Prevent debugging of secure code
[Tools]: ACLE => definition of minimal compiler behaviour for security
[Tools]: dual project management: secure + non-secure in the same development session
Improved Scalability
TrustZone on both profiles
More similar user experience on baseline and mainline profiles
Hardware Divide now also on baseline profile
Higher # of interrupts for baseline => allows building similar MCU systems
Memory Exclusives instruction added to baseline profile to enable multi-core with baseline processor
Read only memory on baseline profile [also in code protection section]
Enhanced Debug:
Breakpoint on all addresses
Watchpoint on areas
Debug non-secure only or both secure/non-secure

30. ARMv8-M Sub-profiles ARMv8-M Baseline: ARMv8-M Mainline:
Scalable architecture
ARMv8-M Baseline:
Lowest cost, smallest, ARMv8-M implementations.
ARMv8-M Mainline:
For general purpose microcontroller products
Highly scalable
Optional DSP and floating-point extensions.
ARMv6-M
ARMv7-M
BASELINE
MAINLINE
ARMv8-M
Today
With the next generation architecture we consolidate the concepts of our small lean v6-M architecture and our general purpose higher performance architecture into a unified ARMv8-M architecture while retaining the benefits of both via sub-profiles.
On the left in blue, the existing architectures with the low area v6-M being a subset of the fully featured v7-M
And mapping onto the right in green we introduce the concept of the v8-M architecture spanning all the way from smallest to fastest.
To do this we introduce sub-profiles, with the v6-M point reflect in the baseline sub-profile, and v7-M reflected in the mainline sub- profile.

31. ARMv8-M Baseline Performance & Scalability
Instruction set feature uplift for baseline microcontroller
Feature
Key benefits
Hardware divide
Faster integer divide operation in hardware.
Removes need for library code.
Compare and branch
Combined compare-with-zero and branch. Faster control code.
Long branch
Long non-linking branch to compliment branch with link. Enables support for cross unit tail calls.
Wide immediate moves
Pointer and large immediate creation without needing a literal load.
Provides a linking mechanism for execute-only code.
Exclusive accesses
Load-link / store-conditional support for semaphore use.
Enables common semaphore handling between CPUs.
Interrupt active bits
Active status of all interrupts individually tracked.
Offers dynamic re-prioritization of interrupts.
Data/Inst; Privileged; Bufferable; Modifiable; Lookup; Allocate; Shareable

32. ARMv8-M Mainline Variants
Comprehensive instruction set support with optional DSP and floating-point extensions
Retains Baseline fundamentals.
Adds extensive 32-bit instruction set
~ 40% performance uplift over Baseline.
Optional 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.
DSP FP
BASE LINE
MAINLINE
Overview of the Mainline instruction set, retains all the features of baseline.
Full backwards compatible with code compiled for baseline.
Adds in all of the instructions from v7-M, an extensive array of 32-bit instructions offering a 40% uplift over baseline.
Retains v7-M options for DSP and FP.
DSP – Adds saturating arithmetic and limited DSP support.
FP – Adds optional single-precision or single-precision and double-precision floating-point.
And so the diagram illustrates how this all fits together,
Core from Baseline.
Extended with more instructions and capabilites in mainline
With optional floating-point and DSP.

33. Memory Protection and Watchpoints
Improved programmability and flexibility
ARMv8-M adopts base and limit style comparators for regions
Replaces previous power-of-two size, sized aligned scheme
Simplifies software development, encouraging creation of safer software
Accelerates programming, potentially reducing context switch times.
MPU configurable down to 32-byte granularity.
Debug variable watchpoints also enhanced to support more flexible scheme.
1kB
16kB
256kB
SINGLE 274kB REGION
PMSAv7
PMSAv8
0x3BC00
0x80400
So, what other challenges are trying to address with v8-M?
Well the first one here is MPU configuration.
Both v6-M and v7-M provide a memory protection unit. The protection unit is configured by programing a region base address and size, where the size must be a power of two and the address must be aligned to the size.
V8-M enhances this, and eases programmability by allowing its MPU regions to be configured by a 32-byte aligned base and limit.
What this means, and what the diagram shows, is that we can produce MPU regions without having to consider joining a number of regions together.
At the same time, the v7-M watchpoint unit uses a similar scheme, and again to simplify use, we have moved to a base and limit scheme.

34. ARM TrustZone Technology
Bringing ARM security extensions to the embedded world
Optional security extension for the ARMv8-M architecture
Security architecture for deeply embedded processors
Enables containerisation of software
Simplifies security assessment of embedded devices.
Conceptually similar and compatible with existing TrustZone technology
New architecture tailored for embedded devices
Preserves low interrupt latencies of Cortex-M
Provides high performance cross-domain calling.
So, [read title and sub-title]
[As per slide].

35. TrustZone for ARMv8-A TrustZone for ARMv8-M
NON-SECURE STATES
SECURE STATES
NON-SECURE STATES
SECURE STATES
Rich OS, e.g.Linux
Secure App/Libs
Non-secure App
Secure App/Libs
Secure OS
Non-secure OS
Secure OS
Secure Monitor
TrustZone for ARMv8-M
About TZ-M
Just like TZ, there’s a safety barrier between software domains
You have Secure and Non-Secure code running on the same processor
Unlike TZ, there’s no SM, improving interrupt latency as NS apps can call S apps directly
Secure Monitor is an execution level only in TZ. Makes transition between SC and NS state. Downside is this makes interrupt latency high. With TZ-M, non-secure app can call secure app directly.
Part of new ARMv8-M architecture
Security architecture for deeply embedded processors
Enables containerisation of software
Simplifies security assessment of embedded devices
Conceptually similar to ARM TrustZone technology, but...
New architecture tailored for embedded devices
Preserves low interrupt latencies
Better cross-domain calling performance
Foundation for high-level security features
Secure remote firmware update
Secure manufacturing
Safe crypto implementations
Secure Thread – Trusted code/data
Secure Handler – Trusted device drivers,
Secure transitions handled by the processor to maintain embedded class latency

36. 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.
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.
ARMv7-M
Non-secure Handler Mode
Non-secure Thread Mode
Secure Handler Mode
Secure Thread Mode
Handler Mode
Thread Mode
ARMv8-M
So TrustZone is implemented by the ARMv8-M security extension.
The extension takes the existing v7-M Thread and Handler modes and duplicates them to provide Secure and Non-Secure version
each with their own stack pointers
The Secure state is for trusted code,
And we have duplicated key resource ensure isolation between the domains, for instance the memory protection units and systick timers.
Also, the Secure side can configure the target domain for an interrupt, routing it to either a Secure or a Non-secure interrupt handler.

37. 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.
Non-secure Interrupt
Running Secure Code
Switch to Non-secure
Run Non-Secure Handler
Push All Registers
Zero All Registers
Pop All Registers
Return from Interrupt
Switch to Secure
So, what about interrupts…
For those not familiar with ARMv7-M, whenever we take an interrupt, the hardware stacks a subset of the registers automatically.
This permits immediate execution of the exception handler without the need to perform additional work in software.
ARMv8-M extends this mechanism in order to provide enhanced security
[Walk through diagram]
If we are running some Secure code and a higher priority Non-secure interrupt arrives
We push all of the registers onto the Secure stack
We then zero the registers to prevent any information being leaved
And then we execute the Non-secure exception handler.
Once we’ve finished with the Non-secure exception it returns
And the hardware recovers all of the registers from the Secure stack.

38. Security Defined by Address
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
All addresses are either Secure or Non-secure.
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.
Load/stores acquire NS attribute based on address
Non-secure access attempts to Secure address = memory fault.
In this architecture security is defined by address,
[walk down slide].

39. 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).
Non‑secure Handler Mode
Non‑secure Thread Mode
Secure Handler Mode
Secure Thread Mode
Calls
Interrupts
So one of the things this enables us to do is to efficiently call from one security domain to another.
Because security is based on instruction address, a call just ends up being a branch to an address of the appropriate security.
This allows very efficient calling by avoiding the Monitor overhead of a classic TrustZone implementation
while at the same time permitting multiple entry points.
The key to all of this is the SG instruction we’ve already touched on, which allows Secure code to define where it is prepared to be called into.

40. Cross-Domain Function Calls
An assembly code level example
Secure memory (Non-secure callable)
NonSecureFunc: BL SecureFunc
<Non-secure code>
SecureFunc: SG
<Secure code>
BXNS lr
Non-secure memory
Enter Secure state
Call
Return to NS
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.

41. Example Compiler Interaction
Coding a Non-secure callable function
Ability to mark Secure code as Non‑secure callable.
Code generation produces:
SG at entry, or an SG veneer
BXNS to permit return to Non‑secure
Header file or linker script to support calling from Non-secure state.
int MySecureFunc(int v)
__attribute(NSEntry) {
return v + 1; }
MySecureFunc: SG
ADDS r0,r0,#1
BXNS lr
extern MySecureFunc();
Let’s take a look to the compiler extensions.
A preprocessor macro allows you to check at compile time whether the code runs in secure or non-secure mode.
And two function attributes support the calls between secure and non-secure mode.
Take a look to this code example. You can see that the attribute nonsecure_callable adds the instructions Secure Gate at the entry and changes to exit to return to non secure code. Almost no overhead to create a secure function.
The linker is also extended and generates a export file for the non secure project that contains all the entry points to the secure world.

42. A Simplified Use Case
Composing a system from Secure and Non-secure projects
Non-secure state
Secure state
Non-secure project cannot access Secure resources.
Secure project can access everything.
Secure and Non-secure projects may implement independent time scheduling.
USER PROJECT
FIRMWARE PROJECT
User application
Start
System start
Function calls
Firmware
Function calls
Communication stack
I/O driver
Function calls
Let us take a quick look to the Registers. You have the R0-R15 that you know from any other ARM architecture.
In the Non Secure state, there are two different stack pointers, but there are also new limit registers that trap stack overflows. And the Secure state has again separate stack pointers for Thread and Handler mode.
The access for these interrupt control registers can be configured. You decide if the non-secure state can modify the execution priority or can disable all interrupts.

43. Microcontroller System
With TrustZone technology
Security driven from master
Dynamically from an ARMv8-M CPU
Statically from a simple DMA.
Propagated by AHB5 interconnect
Compatible with existing Cortex-A.
Enables selective access
Individual flash pages
Regions of memory
Peripherals.
CPU
Non-Secure
DMA
AHB5 Interconnect
Flash
SRAM
Secure Peripheral A
Non-secure Peripheral B

44. Summary
Very few developers have strong security experience (or are event Internet protocol specialists).
With mbed we aim to make it easier for developers to accomplish their goals.
Security support for M-class devices
Complete Internet Protocol stack
Trustzone for V8-M will provide additional hardware-based security features for IoT devices.

45. 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 © 2015 ARM Limited