Defensive execution technologies

Orange coloured security icon
Threats and countermeasures
Arm architecture security features
Side-channel attacks

It is possible for attackers to exploit undesirable side-effects of out-of-order execution and speculative execution in modern processors. This attack can be used to breach the separation between the OS and processes, and between processes to steal data.
Speculation barriers

Introduction of new barrier instructions that can be used to block speculative execution and therefore mitigate cache-speculation side-channel attacks such as Spectre and Meltdown.

View Cache Speculation Issues Update
Stack-smashing attacks

Where software is vulnerable to attack due to errors in the implementation, it is possible to improve the resistance to attack. This is done by recompiling existing software to run on a security-enhanced Instruction Set Architecture, with a compiler that is aware of those ISA enhancements.

Defensive techniques, such as eXecute-Only Memory (XOM) and code-signing, have led to attackers using an ever-increasing range of attacks, such as JOP, ROP, and use-after-free.
Pointer Authentication Code (PAC)

Attacks frequently attempt to subvert software control flow. Pointer Authentication or PAC is a feature introduced in Armv8.3-A to block these types of attacks. The upper bits of a pointer are used to store a PAC, which is a cryptographic signature on the pointer value and some additional specified context. Special instructions have been introduced to add a PAC to a pointer, verify an authenticated pointer's PAC, and restore the original pointer value. This gives the system a way to make cryptographically strong guarantees about the likelihood that certain pointers have been tampered with by attackers, offering the possibility of greatly improving application security.

Read the guide, Learn the architecture: Providing protection for complex software

Branch Target Identification (BTI)


When an attacker has found a vulnerability to exploit, their next aim is to execute code to gain control of the machine they have accessed. Techniques used to modify the control flow include ROP and JOP attacks. These techniques find small sections (called gadgets) of vulnerable programs that can be chained together to achieve the attacker’s goal.

In Armv8.5-A, we introduce BTI. Systems supporting BTI can enforce that indirect branches only target code locations that start with one of the accepted instructions. This reduces the ability of an attacker to execute arbitrary code.

This feature works together with PAC to significantly reduce the number of gadgets available to an attacker.

Read the guide, Learn the architecture: Providing protection for complex software
Memory safety violations

Spatial safety is violated when an object is accessed outside of its true bounds. For example, when a buffer on the stack is overflowed. This may be exploited to overwrite the function’s return address, which can form the basis of several types of attack.

Temporal safety is violated when a reference to an object is used out of scope, typically after the memory backing the object has been re-allocated. For example, when a type containing a function pointer of some kind is overwritten with malicious data, which can also form the basis of several types of attack.

MTE provides a mechanism to detect both categories of memory safety violation. MTE assists the detection of potential vulnerabilities before deployment, by increasing the effectiveness of testing and fuzzing. MTE also assists detection of vulnerabilities at scale after deployment.
Memory Tagging Extension (MTE)

Memory tagging enables developers to identify spatial and temporal memory safety violations in their programs. It is designed to quickly detect memory safety violations and provide robustness against the attacks that are attempting to subvert code. Memory-safety defects account for a large proportion of exploited security vulnerabilities MTE implements a lock and key access to memory. If the key matches the lock, then the memory access is permitted; otherwise, access can be recorded or faulted. In this way, hard-to-catch memory safety errors can be detected and eliminated more easily, which aids reliability and improves product security.

Stronger data protection

A standard permission model is that a more privileged entity can access anything belonging to a less privileged entity. For example, an Operating System (OS) can see all the resources that are allocated to an application. This is not always desirable. Malicious applications might try to trick an OS into accessing data on behalf of the application, which the application should not be able to see.
Privileged Access Never (PAN)

PAN is an Arm security feature that helps to prevent bugs in an operating system kernel (or hypervisor) being exploited to erroneously access memory allocated to user-mode. The idea is that even if the kernel is tricked into accessing a page controlled by user-mode attacker, PAN will prevent the access from occurring.

Read the guide, Learn the architecture: AArch64 memory model

Isolation technologies

Yellow coloured isolation services icon
Threats and countermeasures
Arm architecture security features
Protecting code and data
Defining and enforcing security boundaries is perhaps the single most important technique used in security engineering to protect data and systems. Boundaries are drawn between users, between services and even within transaction flows. These are the boundaries that enforce the principle of least privilege, making it difficult for an attacker to exploit vulnerabilities for commercial gain. TrustZone enables the most sensitive software to be protected in a virtual enclave, enabling much stronger separation where a dedicated security processor is undesirable or uneconomic.
TrustZone

Arm TrustZone technology provides hardware-enforced isolation to protect sensitive software and data that shares the same CPU.

This concept of securing sensitive workloads extends beyond the processor element to encompass memory, bus transactions, interrupts, and peripherals within an SoC.
Isolation between Secure worlds

When vendors want to run multiple Trusted Applications under TrustZone, S-EL2 enables stronger separation between these applications. S-EL2 helps to improve the security and scalability of the TrustZone environment.

S-EL2 also enables Trusted Applications to bring their own Trusted Execution Environment (TEE) – important because there are many different TEEs and it is difficult to port an application to run under a TEE, other than the one it was originally for.
Secure-EL2 extension

The Armv8.4-A architecture introduces the Secure EL2 extension, adding support for virtualization in the Secure world. S-EL2 provides secure partitions for secure services, with strong hardware isolation between the partition and support for running multiple trusted operating systems.

Download the Secure-EL2 white paper
Protecting mainstream compute workloads

Protection of data in use is required beyond silicon manufacturers and OEMS. Mainstream and non-OEM workloads (workloads that normally run outside of the Secure world) can be vulnerable to attack from the host operating system, hypervisor, and adjacent workloads.
Realm Management Extension (RME)

Part of the Arm Confidential Compute Architecture (Arm CCA), the RME establishes a new hardware backed secure environment that extends secure computing to all developers and all workloads. This can be used to protect all application software from privileged software and hardware agents.

Sign up for technical updates to Arm Confidential Compute Architecture.

Common platform security services

Security lock green coloured icon
Threats and countermeasures
Arm architecture security features
Meeting PSA Certified standards

To be secure, all devices require a Root of Trust (RoT) and must be verified against a broad checklist of security requirements. Without using a publicly available framework, the market cannot determine whether a product has the right level of resistance to attack.
Arm platform security specifications

Threat models, specifications, and guides to help developers achieve PSA Certified on Arm-based platforms.

View platform security resources
Communication across security boundaries

Non-standard interfaces can be insecure in novel ways. They require their own security analysis and threat evaluation.

Standard interfaces enable software portability and composability.
Firmware Framework for A-profile architecture (FF-A)

FF-A outlines a standard programming environment and fundamental Root of Trust (RoT) for secure applications on an A-profile application. The framework describes how to use the Virtualization Extension (S-EL2) to isolate software images provided by different vendors.

Read the FF-A specification

Firmware Framework for M-profile architecture (FF-M)

FF-M outlines a standard programming environment and fundamental Root of Trust (RoT) for secure applications on an M-profile device. The framework describes interfaces that standardize communication between the various software images, including communication between images in Secure and Normal worlds.

Read the FF-M specification
Open and standard device firmware

A reference implementation of Secure world software for Armv8-A and Armv8-M, providing SoC developers and OEMs with a reference trusted code base, complying with the relevant Arm specifications.
Trustedfirmware.org

Arm is part of the Open Governance community project, trustedfirmware.org - to collaboratively develop high-quality, open-source Secure world firmware, across the Arm ecosystem.

Through its partnership with Linaro, Trusted Firmware allows quick and easy porting to modern chips and platforms. This forms the foundations of a Root of Trust, trusted execution environment on application processors, or the secure processing environment of microcontrollers.

Visit TrustedFirmware

Standard security APIs

Lightblue coloured puzzle icon
Threats and countermeasures
Arm architecture security features
Confidential Compute software

Standard reference implementations of Confidential Compute stack that can be formally proven, helping to reduce the number of different implementations that relying parties must trust. By minimizing the number of different implementations, it is likely that fewer exploitable bugs will be embedded into products.
Arm Confidential Compute firmware architecture

A standard platform software framework for Arm's Confidential Compute architecture that simplifies hardware design and encourages re-use and portability.

Sign up to receive notifications when the Arm Confidential Compute Architecture specifications are released.
Verification of attestation

Networks or trusted devices must obtain reports of device security state, and then verify these claims to prove compliance across complex systems that span many devices. However, without strong attestation, devices can be spoofed, and it can be impossible to determine whether a device is running authorized firmware and software.
Project Veraison

This open software initiative is creating software that can be used to build device attestation verification services that can support many architectures. To support the Arm Confidential Compute Architecture, contributions to the Veraison project will develop plug-ins that implement the Arm Confidential Compute Architecture attestation model.

Visit GitHub: Veraison
Portable platform security APIs

The PSA APIs provide a set of portable interfaces to cryptographic and security operations that are compatible with a wide range of hardware. These interfaces allow software to use opaque key identifiers rather than the direct use of key material.
PSA Functional APIs

The PSA Functional APIs define the foundations from which security services are built, allowing devices to be secure-by-design. The three APIs (cryptography, storage, and attestation) provide a consistent developer experience for system software and application developers, enabling interoperability across different hardware implementations of the Root of Trust (RoT).
Language-independent security APIs
As developers aim to secure their applications by tying them to a Root of Trust, they inherently tie the application to specific security primitives. This inhibits the ability to move the applications freely from one platform to the next. By implementing platform-independent security APIs, applications can move from one platform to another.
Platform Abstraction for Security project (PARSEC)

The PARSEC, provides a micro-service that maps easy-to-consume security APIs in the language of choice to security primitives found in different hardware. PARSEC is an open-source project that is part of the Cloud Native Compute Foundation (CNCF) sandbox.

Visit GitHub: PARSEC