Better Security at the Flick of a (Compiler) Switch: Enabling Pointer Authentication and Branch Target Identification

Technology is on course to become ever more entrenched in every aspect of our daily lives, with increasing data points and connectivity providing life-changing but complex digital solutions. Managing the security of such solutions is a priority for computing architects at Arm, which is reflected in wider industry attitudes. According to the PSA Certified 2023 Security Report, 75 percent of technology decision makers see security as a business priority.

What is Arm’s strategy for evolving security best practices and technologies?

Arm is committed to a comprehensive strategy for evolving security best practices and technologies with our silicon and software partners. When looking at the security of software, we have targeted various memory related security vulnerabilities in recent architecture releases. In 2019, we introduced Memory Tagging Extension (MTE) as part of the Armv8.5 instruction set. We also introduced:

• Pointer Authentication (PAC) in Armv8.3-A
• Branch Target Identification (BTI) in Armv8.5-A
• Combined PACBTI support in Armv8.1-M.

All these technologies are designed to enhance software reliability, helping to mitigate certain classes of security vulnerabilities, which includes memory safety violations and memory corruption that account for the majority of all serious security bugs.

How are new Renesas microcontrollers leveraging PACBTI for enhanced security?

On 31st October 2023, Renesas announced the new RA8 series of microcontrollers (MCUs), the first to be built on Arm’s highest-performing and most secure Cortex-M processor to date, the Cortex-M85. The RA8 series deploys Arm Helium technology, boosting DSP and ML performance, and enabling innovators to address AI opportunities without compromising on security.

“We are excited to implement the Arm Cortex-M85 with Helium technology into our RA8 Series, delivering the performance uplift required for demanding AI implementations and other use cases,” said Daryl Khoo, Vice President of the IoT Platform Division at Renesas. “In addition, PACBTI and the new RSIP-E51A integrated security engine targeting PSA Certified Level 3 RoT Component certification offer low-touch tamper protection for developers, securing complex applications that are now essential components of products across a variety of industries.”

Alongside a long list of performance and security enhancements from the Arm architecture and Renesas’ security IP, the RA8 series is the first available Cortex-M-based silicon introducing PACBTI security extensions.

What are the benefits of PAC and BTI for software developers?

This blog takes a closer look at how PAC and BTI are used to mitigate security exploits without touching a single line of code in the software base, making them valuable tools for software developers in their applications’ security defences. Both technologies are also essential to security across the ecosystem, with PAC and BTI available across the broad range of Arm IP that cover every corner of the technology market, from sensors to smartphones to supercomputers.

Firstly, what is the common risk related to memory corruption?

Corrupting pointers in a running program can re-route its execution to other bits of software, like gadgets. Gadgets are bits of software that perform functions that support the aims of attackers to cause damage to devices or systems. These functions could be reading arbitrary files or memory locations, opening a socket, spawning another process, or escalating privileges. Attackers can combine those functions to re-use existing software to perform malicious attacks. Gadgets can be found in pretty much every single program and library. They are often used as a foothold to open a machine to more sophisticated remote attacks.

What are Return-Oriented Programming and Jump-Oriented Programming? And how are they related to gadgets?

Return-Oriented Programming (ROP) and Jump-Oriented Programming (JOP) are two attack techniques that use memory corruption to re-direct program execution to usable gadgets. In a ROP attack, the software stack is scanned for gadgets that can be strung together to form a new program. Meanwhile, JOP attacks target sequences that end in other forms of indirect (absolute) branches, like function pointers or case statements, which the attacker can then hijack to string gadgets together.

What is PAC? And how does it protect against these attacks?

PAC is a defense mechanism aimed at thwarting ROP through verifying that addresses are not being modified before they are used. New instructions have been added to the Arm Instruction Set Architecture (ISA) to insert an authentication code into the most significant bits (the upper bits) of a 64-bit pointer return address for Cortex-A and 32-bit for Cortex-M. This then checks the authentication code before using the address to return from function. The end result is that it would not be possible for an attacker to modify the authorization code or the address, or even replace the return address with another return address in the stack, as it triggers an exception which halts the program instead of leading to an arbitrary code execution.

What is BTI?

BTI is a defence mechanism aimed at thwarting JOP. The overall aim of BTI is to provide stronger security guarantees across different “branches” through restricting branches to just the locations that were originally intended to target. This makes it harder for attackers to manipulate the control flow of a program. Branches can be abused for arbitrary code execution by modifying jump pointers, forcing the executed thread to jump to another location in the code, which is usually a desired gadget. BTI adds the concept of a branch target to the Arm Instruction Set Architecture (ISA), so that branching to an instruction that is not a branch target will cause an exception. If an attacker manages to corrupt memory so that a branch is redirected to an invalid location, the execution will halt.

What level of protection is afforded by PAC and BTI?

Through PAC and BTI’s ability to add strict controls to return and branch addresses, the number of usable ROP and JOP gadgets are reduced by magnitudes. The National Security Agency (NSA) found a 50x reduction in usable gadgets in a Linux distribution that utilized PAC and BTI. Meanwhile, in Arm’s own study, the number of usable gadgets on glibc (on Arm Cortex-A CPUs) was decreased by more than 97 percent following the activation of PAC and BTI.

How do I make use of PAC and BTI?

PAC and BTI have been added as part of the Arm ISA across recent architectures, including the latest Armv9 architecture. These instructions are automatically added to binaries when compiling code, so it does not become a collection of usable gadgets. All developers need to do is enable the security protections in their build instructions.

Which processors support PAC and BTI instructions?

All of the Armv9-A CPUs have PAC and BTI built into the processors, with updates and improvements to both security features being made on a regular cadence. For example, in the latest v9 generation of Cortex-A CPUs, Arm introduced a new QARMA3 PAC algorithm for performance improvements when activating the security feature across the Armv9 CPU designs. For Cortex-M processors, Cortex-M85 supports PAC and BTI instructions.

What are the differences between PAC and BTI on Cortex-A and Cortex-M?

Cortex-A operating systems and applications are part of huge ecosystems that require careful attention when deploying security features like PAC and BTI into all binaries. It is not enough to just re-compile everything with the correct options, and the following considerations need to be made:

• Support must be included in the operating system, and;
• Extra care must be taken when mixing manually-written assembler routines with BTI-enabled code.

Devices built on Cortex-M processors tend to have less issues because firmware is often compiled from scratch, making it easier to generate a full software stack that is consistent with PAC and BTI.

The latest Cortex-M processors are closing the gap with application CPUs in terms of performance. Therefore, it should not be surprising that they receive the same level of attention for CPU-oriented threats.

Which compilers support PAC and BTI instructions?

LLVM, which is a set of compiler and toolchain technologies, has supported PAC and BTI across Cortex-A CPU designs since 2018 when LLVM version 8 was released. Meanwhile, GCC, which is an optimizing compiler produced by the GNU project to support various programming languages, has supported PAC and BTI across Cortex-A CPU designs since July 2022 (use -mbranch-protection=standard). GCC version 13.1 added PAC and BTI support for the Cortex-M85 processor in April 2023. For Cortex-M compute platforms, the Arm Compiler 6 (AC6) supports PACBTI instructions see and the IAR Embedded Workbench for Arm supports PACBTI on Arm Cortex-M85. For more details about the hardware support for PAC and BTI, visit this blog.

Which programming languages support PAC and BTI?

In theory, any compiled language that has an LLVM or GCC backend can be supported, but this will depend on where compilers hook into the compiler infrastructure. C and C++ support for PAC and BTI is included in both compiler suites. Languages like Rust and Go already include support for PAC and BTI as experimental features. For more information on Rust experimental support for PAC and BTI visit here.

Are there any real-world examples of projects that are already using PAC and BTI instructions?

Google’s Chromium project and Javascript V8 engine are now distributed for Arm64 with PAC and BTI instructions compiled in. Some Linux distributions, like Debian and RedHat have already deployed compatible binaries to support PAC and BTI. Meanwhile, others are considering both security features for their next releases. For example, SuSE’s Tumbleweed project supports PAC, BTI and other Arm-specific features. More information can be found at the following links:

• Enhancing Chromium’s Control Flow Integrity with Armv9
• SuSE Tumbleweed supports PAC/BTI and other Arm-specific features
• Fedora support for Aarch64 Pointer Authentication

What if the same code needs to run on older processors?

PAC and BTI instructions (PAC, PACBTI, AUT) are part of the NOP (No Operation) space. For older processors that do not recognize PAC and BTI instructions, they are treated as NOP and skipped. The same programs still work, but the security benefits will not be realized.

What is the impact of PAC and BTI on performance and code size?

Some standard benchmarks have been run on a Cortex-M85 RA8D1 from Renesas. See tables below.

Compiler: Arm Compiler 6.20 with –mbranch-protection=standard

	No PacBTI		With PacBTI
Compiler  Optimization level	Code size (bytes)	perf (coremark/Mhz)	Code size (bytes)	perf (coremark/Mhz)
Os	27568	4.143	31824	3.860
Ofast	37160	5.496	40900	5.236
Omax	37848	6.194	40756	6.133

	No PacBTI		with PacBTI
Compiler  Optimization level	Code size (bytes)	perf (audiomark/Mhz)	Code size (bytes)	perf (audiomark/Mhz)
Os	70616	3.874	77072	3.923
Ofast	88472	3.835	94440	3.887
Omax	86456	3.864	90376	3.859

	No PacBTI		with PacBTI
Compiler  Optimization level	Code size (bytes)	perf (iteration/sec)	Code size (bytes)	perf (iteration/sec)
Os	44670	49.23	51016	48.94
Ofast	63942	50.4	69984	50.15
Omax	69438	61.35	74160	61.72

As expected, PAC impacts function calls as this is the moment when pointer authentication takes place. For compute-intensive firmware spending most time in digital signal processing (DSP) or matrix computations, the impact is minimal. Performance is barely impacted, and that impact can be mitigated by using compiler optimizations which lead to similar performance for an increase in code size.

Safe and secure digital experiences built on Arm

Arm is constantly introducing more built-in security features to remove ways for attackers to exploit devices remotely or locally, whether they run in a data center or are consumer tech or embedded products. Having built-in protection against ROP and JOP style attacks through PAC and BTI makes existing code far safer and more secure. With the Armv8 and Armv9 architectures prevalent across the Arm ecosystem, PAC and BTI are able to provide security benefits at scale, with the world’s digital security being built on Arm.

Interested readers may want to check the whitepaper published by SiPearl about Anti-malware protection on Arm64 systems, which explains PAC and BTI in more depth.