PACStack: an Authenticated Call Stack

In ROP, the adversary exploits a memory vulnerability to manipulate return addresses stored on the stack, thereby altering the program’s backward-edge control flow. ROP allows Turing-complete attacks by chaining together multiple gadgets, i.e., adversary-chosen sequences of pre-existing program instructions that together perform the desired operations. ARM architectures use the link register ($\mathtt{LR}$) to hold the current function’s return address. $\mathtt{LR}$ is automatically set by the branch with link (bl) or branch with link to register (blr) instructions that are used to implement regular and indirect function calls. Because $\mathtt{LR}$ is overwritten on call, non-leaf functions must store the return address onto the stack. This opens up the possibility of ROP on ARM  [30].

The ARMv8.3-A PA extension supports calculating and verifying pointer authentication codes (PACs) [4]. PA is at present deployed in the Apple A12, A13, S4, and S5 systems-on-chip (SoCs) and is going to be available in all upcoming ARMv8.3-A and later SoCs. A pac instruction calculates a keyed tweakable MAC, $\mathtt{H_{K}}(A_{P},M)$, over the address $A_{P}$ of a pointer $P$ using a 64-bit modifier $M$ as the tweak. The resulting authentication token, referred to as a PAC, is embedded into the unused high-order bits of $P$. It can be verified using an aut instruction that recalculates $\mathtt{H_{K}}(A_{P},M)$, and compares the result to $P$’s PAC .

Since the PAC is stored in unused bits of a pointer, its size is limited by the virtual address size (VA_SIZE in Figure 1) and whether address tagging is enabled [4]. On a 64-bit ARM machine running a default Linux kernel, VA_SIZE is 39, which leaves 16 bits for the PAC when excluding the reserved and address tag bits. PA provides five different keys; two for code pointers, two for data pointers, and one for generic use. Each key has a separate set of instructions, e.g., the autia and pacia instructions always operate on the instruction key $A$, stored in the APIAKey_EL1 register. Access to the key registers and PA configuration registers can be restricted to a higher exception level (EL) . Linux $\mathrm{v}5.0$ ³³ 3 https://kernelnewbies.org/Linux_5.0#ARM_pointer_authentication adds full support for PA, such that the kernel (at EL 1) manages user-space (EL 0) keys and prevents EL 0 from modifying them. The kernel generates new PA keys for a process on an exec system call.

As currently specified, PA does not cause a fault on verification failure; instead, it strips the PAC from the pointer $P$ and flips one of the high-order bits such that $P$ becomes invalid. If the invalid pointer is used by an instruction that causes the pointer to be translated, such as load or instruction fetch, the memory management unit issues a memory translation fault.

The current authenticated return address $aret_{n}$, is secured by keeping it exclusively in a CPU register which we call the chain register ($\mathtt{CR}$) . Note that reserving exclusive use of a register is also a requirement for current shadow stack implementation for the 64-bit ARM architecture [14] and has been proposed for shadow stacks on the x86 architecture [10].

ACS protects the integrity of backward-edge control-flow transfers. Combined with coarse-grained forward-edge CFI (Assumption A2), it ensures that: 1) immediately after function return, the $aret_{n}$ in $\mathtt{CR}$ is valid, 2) at function entry the $aret_{n-1}$ stored in $\mathtt{CR}$ is valid, and 3) $\mathtt{CR}$is always used as or set to a valid $aret$. This ensures that token updates are done securely, and that the ACS instrumentation cannot be bypassed or used to generate arbitrary authenticated return addresses.

Though $aret_{n}$ is protected by hardware, the size $b$ of the authentication token $auth$ can be limited by the implementation. Using a PAC as the token would typically limit it to 16 bits. This is significant, as collisions can be found after $\mathcal{A}$ has seen, on average, approximately $1.253\cdot 2^{b/2}$ tokens [47, Section 1.4.2] (e.g., 321 tokens for $b=16$). Despite this, we can still prevent $\mathcal{A}$ from recognizing collisions (R2), thus forcing $\mathcal{A}$ to guess—with a success probability $2^{-b}$—which authenticated return addresses yield a collision. The $auth$ of any $aret$ stored on the stack is masked using a pseudo-random value derived from the previous $aret$ value:

The mask is exclusive-OR-ed with $\mathtt{H_{K}}(ret_{i},aret_{i-1})$ after it is generated and before it is authenticated, thereby preventing $\mathcal{A}$ from identifying opportunities for pointer reuse. We discuss the security of masking in Section 6.2.1.

A brute force attack where $\mathcal{A}$ guesses an $auth$ token succeeds with probability $p$ for a $b$-bit $auth$ after $\frac{\log(1-p)}{\log(1-2^{-b})}$ guesses, provided that a failed guess terminates the program and subsequent program runs use a new key to generate $auth$ tokens. This assumption is similar to prior PA-based solutions [35] and is consistent with current PA behavior in Linux 5.0. However, if pre-forked or multithreaded programs share the key, $\mathcal{A}$ can target a vulnerability in a sibling. Unless a failed authentication terminates the entire process tree, $\mathcal{A}$ can then attempt a new guess against another sibling process without resetting the key. In this scenario, $2^{b-1}$ guesses on average are enough to obtain a modifier with respect to which some combination of pointer and authentication token is valid. Since this modifier becomes the next authenticated return address, the process can be repeated to use the injected address. Because the two guesses can be done separately using a divide-and-conquer strategy, this requires on average $2^{b}$ guesses to allow $\mathcal{A}$ to jump to an arbitrary address, rather than $2^{2b}$ that are needed when the guesses are independent.

Liljestrand et al. [35] recommend hardening pre-forking and multi-threaded applications against guessing attacks by having the application restart all of its processes if the number of PAC failures in child processes exceeds a pre-defined threshold. We recommend an alternative mitigation specific to ACS: "re-seeding" the $auth$ calculation after a fork or thread creation. For example, calculating $auth_{0}=\mathtt{H_{K}}(ret_{0},init)$ where $init$ corresponds to the process or thread ID. This solution is straightforward to apply to threads, as a return from the function starting the thread causes the thread to exit. Crucially, re-seeding prevents a divide-and-conquer guessing strategy and requires on average $2^{2b}$ guesses. Therefore, the ACS for the thread stacks can be made disjoint from the main ACS chain. However, forked processes may use $auth$ tokens in stack frames inherited from the parent process. If a child process never returns to inherited stack frames, re-seeding any new $auth$ tokens beyond the point of the fork is sufficient. However, if the child process returns to inherited stack frames, the ACS must be re-seeded starting from $auth_{0}$ by rewriting any $auth$ tokens in pre-existing stack frames; similar to some stack canary re-randomization schemes [43, 25].

The C standard includes the setjmp / longjmp programming interface, which can be used to add exception-like functionality to C. The longjmp C function executes a non-local jump to a prior calling environment stored using the setjmp function. At setjmp, callee-saved registers (whose values are guaranteed to persist through function invocations), as well as the stack pointer $\mathtt{SP}$, and the return address are stored in the given jmp_buf buffer. Calling longjmp using an expired buffer, i.e., after the corresponding setjmp caller has returned, results in undefined behavior (the implications of this are discussed in Section 9.1). Because jmp_buf also stores the last authenticated token, ACS needs a mechanism to ensure its integrity when using setjmp and longjmp.

While in memory, the integrity of jmp_buf cannot be guaranteed. Nonetheless, the stored $auth_{i}$ is bound to the corresponding $auth_{i-1}$ on the setjmp caller’s stack. This ensures that longjmp always restores a valid ACS state. To limit the set of values $\mathcal{A}$ can inject into jmp_buf, we replace the setjmp return address $ret_{b}$ in jmp_buf with $aret_{b}$, defined as:

where $\mathtt{SP}_{b}$ is the $\mathtt{SP}$ value stored in jmp_buf. When executing longjmp, $aret_{b}$ is recalculated based on the buffer values to verify that the stored $auth_{i}$ was stored by a setjmp. $\mathcal{A}$ cannot generate the $aret_{b}$ value for an arbitrary $auth_{i}$, nor replace $aret_{b}$ with a previously observed $auth_{i}$. But, since longjmp explicitly allows jumping to prior states, ACS cannot ensure that the target is the intended one, i.e., $\mathcal{A}$ could substitute the correct jmp_buf with another. Shadow stacks share a similar limitation [17], and cannot guarantee that the intended state has been reached, only that the return address (and stack pointer) in that state is intact.

PACStack uses the ARM general purpose register X28 as $\mathtt{CR}$ for storing the last authentication token. X28 is a callee-saved register, and so, any function that uses it must also restore the old value before return. By using X28 as $\mathtt{CR}$, PACStack libraries or code can be transparently mixed with uninstrumented code (R3). We discuss the security implications of mixing instrumented and uninstrumented code in Section 9.2.

To prevent $\mathcal{A}$ from identifying PAC collisions that can be reused to violate the integrity of the call stack, PACStack masks all authentication tokens values before storing them on the stack. A pseudo-random value is obtained by generating a PAC for address 0x0, $\mathtt{pacia}(0,aret_{i-1})$ (Listing  ❶, ❺). By using $\mathtt{pacia}$ we efficiently obtain a pseudo-random value that can be directly applied to the authentication token part of $aret$ using only an exclusive-or instruction (eor ❷, ❻).

Because this construction uses the same key to generate both authentication tokens and masks, $\mathcal{A}$ must not obtain an $aret_{i}$ for a $ret_{i}=\mathtt{0x0}$ and any existing $aret_{i-1}$. PACStack will never generate such $aret$ values, as the return address never points to memory address zero. To prevent leaking the mask directly, it is cleared after use (❸, ❼). Consequently no $\mathtt{H_{K}}(0,x)$ value is visible to $\mathcal{A}$ nor is it possible to pre-compute without the confidential PA key.

This approach to masking requires two additional PAC calculations for each function activation. PACStack supports instrumentation with or without masking. We discuss the security of PAC masking in Section 6.2.1.

PACStack binds jmp_buf buffers to the $aret_{i}$ at the time of setjmp call by replacing the setjmp return address $ret_{b}$ with its authenticated counterpart $aret_{b}$ before setjmp stores it to the jmp_buf (Section 4.4). The libc implementation is not modified; instead setjmp / longjmp calls are replaced with the wrapper functions in Listings  and .

The setjmp_wrapper (Listing ) replaces the return address in $\mathtt{LR}$ with $aret_{b}$ and then executes setjmp, which stores it in the buffer. The longjmp_wrapper (Listing ) retrieves $aret_{b}$, $aret_{i}$, and the $\mathtt{SP}$ values from jmp_buf, verifies their values and writes $ret_{b}$ into jmp_buf before executing longjmp.

The values of ARMv8-A general purpose registers are stored in memory when entering EL 1 (i.e. kernel-mode) from EL 0 (i.e. user-mode), for example during context switches and system calls. This must not allow $\mathcal{A}$ to modify the $aret$ values or read the mask, which are both exclusively in either $\mathtt{CR}$ or $\mathtt{LR}$ during execution (Listings  and ), but must be stored in memory during the context switch. On ARMv8-A, system calls are implemented using the supervisor call instruction (svc) that switches the CPU to EL 1 and triggers a configured handler. On 64-bit ARM, Linux $\mathrm{v}5.0$ uses the kernel_entry⁵⁵ 5 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/kernel/entry.S?h=v5.0 macro to store all register values on the EL 1 stack, where they cannot be accessed by user-space processes. During context switches, callee-saved registers (including $\mathtt{CR}$) and $\mathtt{LR}$ are stored in struct cpu_context⁶⁶ 6 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/include/asm/processor.h?h=v5.0 which belongs to the in-kernel task structure and cannot be accessed by user space. The $\mathtt{CR}$ and $\mathtt{LR}$ values of a non-executing task are thus securely stored within the kernel, beyond the reach of other processes or other threads within the same process. Thus, no kernel modifications are needed to securely apply PACStack to multi-threaded applications.

Reuse attack on PA-based schemes are possible when the modifier is calculated with known or predictably repeating values. Using the $\mathtt{SP}$ can mitigate reuse attacks (Section 2.2.1). However, -mbranch-protection generates the PAC immediately on function entry, before modifying the $\mathtt{SP}$ value to allocate stack space. All functions called from within a code segment use the same modifier unless there are dynamic stack allocations. Moreover, because the stack is typically aligned to 8 bytes, the $\mathtt{SP}$ value will often repeat. For example, a less than $1s$ test execution of a SPEC CPU 2017 benchmark (538.imagick_r) already shows multiple collisions, with $5349$ distinct ($\mathtt{LR}$,$\mathtt{SP}$) pairs, but only $914$ unique $\mathtt{SP}$ values. shows a minimal example where all called functions will end up using the same modifier and thus have interchangeable signed return addresses.

A generic representation of an attack against ACS is shown in Figure 4. Under normal operation, function $C$ returns to $A$ if called from $A$ (Figure 4(a)); i.e., when called from $A$, the return address of $C$ is an address $ret_{A}$ in $A$. The goal of $\mathcal{A}$ (Figure 4(b)) is to cause $C$ to return to some other address $ret_{B}$.

Since the authenticated return address $aret_{A}$ containing $ret_{A}$ is protected from $\mathcal{A}$, in order to perform a backward-edge control-flow attack, $\mathcal{A}$ must achieve two goals successfully:

AG-Jump: Obtain an authenticated return address $aret_{B}$, valid with respect to some known modifier, which will validate successfully when $C$ returns.

AG-Load: Violate the integrity of the call stack such that the $\mathtt{LR}$ register is loaded with $aret_{B}$ from AG-Jump rather than the correct authenticated return address $aret_{A}$.

This requires two returns: one from a ‘loader’ function to load $\mathcal{A}$’s $aret_{B}$ into $\mathtt{LR}$, and another from $C$ to the return address $ret_{B}$ contained in $aret_{B}$.

In the analyses below, we treat the $auth$ token $\mathtt{H_{K}}($P$,m)$ as a random oracle with respect to both the pointer $P$ and modifier $m$. This means that if $\mathtt{H_{K}}(P,m)$ has never been computed by a function call, $\mathtt{H_{K}}(P,m)$ will match any value with probability $2^{-b}$, independently of any other value $\mathtt{H_{K}}(P^{\prime},m^{\prime})$. In the analysis below we assume that programs that share the same PA keys between multiple processes or threads employ the mitigation strategy against brute-force attacks described in Section 4.3. This assumption and the design of ACS ensure that there is no authentication oracle available: the only way to test whether an $auth$ token is valid with respect to some address and modifier is to attempt to return using the address and token, triggering a crash if the token is incorrect. The difficulty of achieving these goals therefore depends on whether $\mathcal{A}$’s desired control-flow violation follows the call graph of the program and whether $auth$ tokens are masked. Violating control-flow integrity while still traversing the call graph is easier because this allows $\mathcal{A}$ to harvest $auth$ tokens and search for collisions; violations that do not follow the call graph are more difficult because they require that $\mathcal{A}$ make one or more guesses, risking a crash.

PACStack must ensure the integrity of $aret_{n}$ and the confidentiality of the masks. The former is achieved by storing $aret_{n}$ in $\mathtt{CR}$, which is reserved for this purpose, not used by regular code, and hence, inaccessible to $\mathcal{A}$ (Section 5.1). The latter is maintained as the mask is re-generated each time it is needed and cleared after use (Section 5.2). This holds true also in multi-threaded environments (Section 5.4). Traditional CFI solutions are unable to withstand control-flow bending [11]: attacks where each control-flow transfer follows the program’s CFG, but the program execution trace conforms to no feasible benign execution trace. Schemes like PACStack and shadow call stacks are not susceptible to backward-edge control-flow bending because they precisely protect the integrity of the return addresses. $\mathcal{A}$ cannot trick PACStack to deviate from an expected return flow by replacing $aret_{n}$ with a valid, but outdated $aret$ value, because PACStack never writes $aret_{n}$ onto the stack. $\mathcal{A}$ also cannot reliably exploit PAC collisions to replace part of the $aret$ chain, as each $aret$ is masked. $\mathcal{A}$ cannot tamper with the instrumentation itself by modifying the instructions in memory (Assumption A1). By requiring coarse-grained forward-edge CFI (Assumption A2), PACStack ensures that $auth$ token calculations and masking are executed atomically and cannot be used to manipulate $ret_{i}$, $aret_{i-1}$ or the mask during the function prologue and epilogue. This holds when the forward-edge CFI is susceptible to control-flow bending (Section 3).

We ran benchmarks on Amazon EC2 using the SPEC CPU 2017 benchmark package⁸⁸ 8 https://www.spec.org/cpu2017. To guarantee exclusive access to the hardware, we used Amazon EC2 a1.metal⁹⁹ 9 https://aws.amazon.com/ec2/instance-types/a1/instances, each with 16 64-bit ARMv8.2-A cores. As these CPUs do not support PA, we instrumented benchmarks with the PA-analogue. For comparison, we measured run-time overheads of:

We measured PACStack by instrumenting all function entry and exit points, excluding leaf functions that do not spill $\mathtt{LR}$ or the $\mathtt{CR}$ (this is similar to the heuristic used by -mbranch-protection). We measured both full PACStack and PACStack without masking (PACStack-nomask).

ShadowCallStack saves a function’s return address in a separately-allocated shadow stack and then uses the protected return address when performing a return. On 64-bit ARM the $\mathtt{X18}$ register is reserved to hold a reference to the shadow stack. To perform a comparison against PACStack using the GNU C library (glibc) we ported ShadowCallStack support to glibc. Due to compatibility issues [52], we did not run the perlbench benchmarks with ShadowCallStack.

Our measurements include all C SPECrate and SPECspeed benchmarks, compiled with -O2 optimizations and flags to enable the measured instrumentation. The suite is self-contained, avoiding the need to instrument system libraries. For each benchmark, we compared the performance of the baseline (with all evaluated instrumentations disabled) to the measured configuration. Figure 5 shows the mean overheads (w.r.t the baseline). Table 2 shows the geometric mean of the overheads, excluding perlbench which was incompatible with ShadowCallStack. On C++ benchmarks we observed overheads of 2.0% (PACStack) and 0.9% (PACStack-nomask). Due to compatibility issues with ShadowCallStack and -mbranch-protection, we limit our comparison to the C benchmarks.

As expected, -mstack-protector-strong outperforms other instrumentations (but provides the weakest protection). In terms of added instructions, -mbranch-protection is similar to PACStack-nomask; the performance difference is likely due to PACStack reserving the $\mathtt{CR}$ register and the additional store when saving it the stack. PACStack-nomask and ShadowCallStack have similar memory requirements (i.e., one extra store per function call), and show similar performance overheads. The overhead of PACStack is proportional to the frequency of function calls; benchmarks with few function calls are affected less than the benchmarks with frequent function calls. For instance, the 519.lbm_r benchmark involves computations related to fluid dynamics and consists of large nested loops with few function calls. Consequently we see little effect on the performance of 519.lbm_r.

Based on these results, we expect the overhead for both PACStack configurations to be

We evaluated the efficacy of PACStack in a real-world setting using a SSL/TLS transactions per second (SSL TPS) test on the NGINX ¹⁰¹⁰ 10 https://www.nginx.com/ open source web server software. SSL TPS measures a web server’s capacity to create new SSL/TLS connections back to clients. Clients send a series of HTTPS requests, each on a new connection. The web server sends a 0-byte response to each request. The connection is closed after the response is received. We chose the SSL TPS test (instead of measuring throughput) to ensure that the load on the web server is CPU-bound, allowing us to estimate the upper bound for PACStack’s impact on NGINX performance.

We conducted our tests on two separate Amazon EC2 A1 instances connected via elastic network interfaces with up to 10 Gbps capacity. The web server (on an a1.metal instance, running NGINX 1.17.8 with OpenSSL 1.1.1d) and the client (on an a1.4xlarge instance) ran the 64-bit ARM version of Ubuntu 18.04. We configured the server to use the ECDHE-RSA-AES256-GCM-SHA384 cipher with a 2,048-bit RSA key for HTTPS. The client used wrk¹¹¹¹ 11 https://github.com/wg/wrk (version of April 18, 2019), a modern HTTP benchmarking tool, to generate traffic. We configured wrk in the same way as in a test on NGINX performance conducted by F5 Networks.¹²¹² 12 https://www.nginx.com/blog/nginx-plus-sizing-guide-how-we-tested/ We ran a total of 15 copies of wrk on the client machine for 3 minutes each.

We repeated the test with four and eight NGINX worker processes instrumented with PACStack and PACStack-nomask, and compared the results with uninstrumented baseline performance. In both configurations we also instrumented NGINX’s dependencies (OpenSSL, pcre and zlib libraries). All binaries were compiled with -O2 optimizations. We summarize the results in Table 3, showing a 4–7% overhead for PACStack-nomask and 6–13% overhead for PACStack. These results are consistent with the performance overheads measures for SPEC CPU 2017 (Section 7.1).

ConFIRM is a set small micro-benchmarking suite designed to test compatibility and relevance of CFI solutions [52]. The suite is designed to test various corner-cases—e.g., function pointers, setjmp/longjmp and exception handling—that often cause compatibility issues for CFI solutions. ConFIRM is designed for x86-based architectures and includes some tests that are exclusive to the Microsoft Windows operating system. Of the 18 64-bit Linux tests 11 compiled and worked on AArch64; these included virtual and indirect function calls, setjmp/longjmp, calling conventions, tail calls and load-time dynamic linking. We ran these benchmarks on the FVP (to guarantee functional equivalence to PA-capable hardware) and confirmed that the tests passed with or without PACStack.

The setjmp / longjmp interface has traditionally been used to provide exception-like functionality in C. However, modern coding standards for C and C++ that aim to facilitate code safety, security, and reliability consider them harmful and forbid their use, e.g., MISRA C:2004 [26, Rule 20.7] and JSF AV C++ [36, Rule 20]. Recall from Section 4.4 that calling longjmp with an expired jmp_buf is undefined behavior. For PACStack, this means that although the $aret_{b}$ in jmp_buf is tied to the corresponding $\mathtt{SP}$ and $auth_{i}$, its freshness cannot be guaranteed. $\mathcal{A}$ can modify jmp_buf to contain the previously used $aret_{b}$ and $\mathtt{SP}_{b}$, but must also modify the stack-frame at $\mathtt{SP}_{b}$, such that it contains the prior $aret_{i}$. This allows a control-flow transfer to a previously valid setjmp return site and $\mathtt{SP}$ value. To prevent reuse of expired jmp_buf buffers, longjmp can be rewound step-by-step, i.e., conceptually performing returns until the correct stack-frame is reached.

We plan to extend PACStack support to LLVM libunwind ¹³¹³ 13 https://github.com/llvm/llvm-project/tree/master/libunwind – it does frame-by-frame unwinding of the call stack. By validating the ACS on each stack frame unwinding, PACStack can ensure that a fresh and valid state is reached.

As C++ exceptions also cause irregular stack unwinding they pose a similar challenge. But C++ does finer-grained stack unwinding to correctly destroy objects in unwound stack frames. The LLVM libcxxabi library will, depending on configuration, use libunwind for this purpose. With PACStack support in libunwind, we will be able to secure both setjmp / longjmp and support C++ exception handling.

Interoperability with unprotected (uninstrumented) code is an important deployment consideration. On one hand, PACStack-protected applications may need to interoperate with unprotected shared libraries. On the other, unprotected applications may need to interoperate with PACStack-protected shared libraries. The latter scenario is relevant for deployment in mobile operating systems like Android, where multiple stakeholders provide application binaries to consumer devices. The deployment of PACStack, or any other run-time protection mechanism, is likely to be driven by OEMs that enable specific protection schemes for the operating system and system applications. However, OEMs are not in control of native code deployed as part of applications. It should be possible for one version of the shared libraries shipped with the operating system to remain interoperable with both PACStack-protected, and unprotected apps.

In Section 5.1 we explain how the use of callee-saved registers allows PACStack to remain interoperable with unprotected code. Recall that because $\mathtt{CR}$ is a callee-saved register it will be restored upon return. However, PACStack cannot guarantee that $\mathtt{CR}$ remains unmodified during the execution of the unprotected code that could temporarily store its value on the stack. To meet the security guarantees (Section 6), PACStack instrumentation must be applied to both the application and any shared libraries. But partial protection, e.g. PACStack-protected shared libraries can significantly raise the bar for the attacker, as calls into protected functions can still benefit from return address authentication. Common shared libraries like libc are a popular source for gadgets for run-time attacks because of their size and availability. Because functions in a PACStack-protected library validate the return address in returns from library functions, they effectively remove a potentially large set of reusable gadgets from $\mathcal{A}$’s disposal.