In ARM® Cortex®-A class CPUs, the Memory Management Unit (MMU) and Operating System (OS) work together to protect address spaces. A process running in unprivileged mode has its own virtual address space and cannot access other processes’ memory or memory mapped I/O devices directly using physical addresses. Any attempt to do this is met with a memory access violation exception. This is possible because of the hardware support offered by the Cortex-A class CPUs in the form of the MMU. Access to resources outside a process’ virtual address space is possible only by moving to a higher privilege level. This is normally done via a system call to the OS using an SVC instruction.
Embedded and deeply embedded systems powered by Cortex-M CPUs have to honor real-time constraints and therefore cannot afford to have as many layers of abstraction to protect system resources. Cortex-M CPUs do not have MMUs for this reason. The applications running on Cortex-M processors often use an OS, usually a Real-Time Operating System (RTOS). Cortex-M CPUs have a Memory Protection Unit (MPU) that collaborates with the OS to implement a memory protection mechanism. Typically, the MPU and OS collaborate to create a privilege-stack. Unprivileged software can communicate with privileged software using well-defined APIs similar to the stacks on Cortex-A cores created by the OS and MMU.
Privilege levels ensure data protection to a certain extent, but in the real-world, privileged software could contain vulnerabilities. As IoT applications become more complex, ensuring privileged software is free of vulnerabilities becomes challenging. In such cases, the MPU alone is insufficient to protect data. In processors that have an MPU in a scenario where an interrupt handler is untrusted, software wrappers are used to sandbox the handler into an unprivileged level to protect other resources. This adds additional overhead to servicing untrusted interrupts because the sandboxing involves reprogramming the MPU each time an untrusted handler is executed.
ARMv8-M introduces Security Extensions that provide hardware features for more secure devices. The Security Extensions allow the protection of trusted and system resources from untrusted handlers and applications. They can be executed without the additional software sandboxing overheads of reprogramming the MPU. The Security Extensions collaborates with the associated software model to provide a mechanism to restrict access to system resources and processes through well-defined interfaces similar to system calls, thereby ensuring a higher level of protection and also offering an implicit privilege-stack.
Security Extensions for ARMv8-M provide a mechanism to create a protected space within a processor system design (Figure 1). This allows multiple security domains to exist in the application, which might be required when there are multiple sources of firmware on the chip, or when applications have security requirements.
Figure 1: High level concept of Security Extensions for ARMv8-M
As outlined, access into the secure domain is provided through well-defined interfaces offered by software in the secure domain. These interfaces are the only way resources in the non-secure domain can access protected resources in the secure domain. Any direct access to resources in the secure space is met with security access violations. Once control is with a resource in the secure domain, the non-secure domain has no control over what happens in the secure domain.
Figure 2: Access to secure resources only through calls to secure state
Protection behind the secure domain creates implicit privilege levels – you can consider the non-secure domain as being at a lower privilege level than the secure domain. This is similar to what happens in an OS-based software stack (Figure 3) where all system resources are made available only across a privilege boundary.
Figure 3: Access to system resources only through calls to privileged level.
System resources in a higher privilege level are protected from applications/resources at a lower privilege level by layers of abstraction. These resources can be accessed only through well-defined interfaces provided by resources at a higher privilege level. For example, if a user-mode application wants to access a peripheral such as the serial port or the video buffer, it needs to make a system call that enters privileged-mode. The user-mode application cannot directly write to the video buffer or access the serial port because it is at a lower privilege level – it has to ask the kernel. Any direct access to system resources results in a memory-access violation.
Crossing privilege levels and security domains can be considered as analogous. Privilege level transitions happen through system calls in a multi-privilege software stack. System calls are rarely called directly from user code – they are wrapped in libraries (eg. Glibc in Linux) where the system call is actually set up(Figure 4a). When user code calls a library routine, the library routine marshals the parameters, sets up the system call number and invokes the instruction (eg. SVC) that puts the processor in privileged mode and hands over control to the kernel. The kernel then services the application’s request for a system resource. During this service operation of the kernel, the user mode application has little or no control.
Figure 4a: Privilege Call
Figure 4b: Secure Call
Figure 4: Privilege Call vs Secure Call
Transitions into secure state happen through well-defined interfaces offered by the secure software. Entry into secure code can only happen through these interfaces. Like library wrappers for system calls, secure calls from non-secure domains happen through Secure Gateway wrappers (Figure 4b). The Secure Gateway wrapper sets up the Secure Gateway (SG) instruction to transition the security state and makes the call to the actual code in secure code – this is similar to the software interrupt method of changing privilege levels during system calls.
ARMv8-M Security Extensions (SE) provides an implicit mechanism to implement privilege levels. SE supplements the MPU and improves the capability of the system to provide enhanced security. It does all this whilst still honoring real-time constraints.
The role of SE technology is more than just IP protection. Since secure operations can also be protected, the same technology can be used to safe guard critical system operations. As a result, it is possible to deploy ARMv8-M based systems in a wide range of applications, such as industrial and automotive, with SE being used as a system reliability enhancement feature. This provides the potential for new ranges of industrial and automotive microcontroller devices.
In conclusion, the ARMv8-M Architecture will power the next generation of ARM Cortex-M processors. The Security Extensions technology in this architecture helps address one of the most important challenges in future IoT and embedded systems.
Whitepaper - ARMv8-M Architecture Technical Overview
A good introduction for ARMv8-M Security Extensions.