Summary

Implement PAC-RET branch protection on Linux/AArch64

Motivation

PAC (Pointer Authentication Code) is an AArch64 hardware feature which provides a set of tools to guard against various types of attacks at the cost of a small performance overhead. For more details see the Arm® Architecture Reference Manual : D5.1.5 Pointer authentication in AArch64 state For a general background see Providing protection for complex software

PAC-RET is used to describe using PAC to protect against return-oriented programming (ROP) attacks by ensuring return addresses are signed when stored on the stack. This is the only PAC based protection which can be provided without changing the ABI and is currently the only one implemented by GCC/LLVM. In addition, GCC/LLVM only uses the set of PAC instructions which are NOPs on non-PAC systems, this allows the binaries to run on all AArch64 systems.

In order to ensure protection across a PAC Linux system, all applications should be compiled the same way; therefore OpenJDK should provide the same protection. Doing this will significantly reduce the number of possible ROP gadgets; there are almost 850 unique ROP gadgets in libjava.so and over 100,000 in a simple helloworld.java execution.

Additional protections, such as those provided by the PAuth ABI Extension to ELF for the Arm® 64-bit Architecture (AArch64) and the MacOS arm64e ABI, require implementing new ABIs. These are out of scope for this JEP.

Description

Provide PAC-RET protection for both the VM and generated JIT code.

• If the branch-protection flag is available in the compiler used to build OpenJDK, then enable it by default (with the option to override).
• When generating code, emit PAC instructions to sign/authenticate the return address when it is saved to/restored from the stack. Provide a development only flag to override this behaviour.
• Emit a warning or error when a native library that does not contain the PAC flag in its ELF header is loaded by the Java application.

The release build cannot use run time logic to decide whether to generate PAC instructions as this would provide a way for an attacker with data write access to disable PAC protection in generated code. This means that in order to run on non-PAC systems, only the NOP based instructions will be used.

Testing

Testing will include, but not be limited to, regression testing with jtreg and various other benchmark suites. The execution environment will include Linux VMs on Apple Silicon as well as any additional PAC hardware that becomes available, and non-PAC AArch64 systems.

Risks and Assumptions

Assumption: Implementing this change will result in an acceptable performance overhead on all AArch64 systems.

• Code size will be increased by two instructions every non-leaf VM function and Java method. Assuming similar results to that shown by GCC/LLVM, this will be an increase of 0.35%.
• For systems without PAC, the extra instructions will be treated as NOPs, resulting in a negligible performance impact.
• For systems with PAC, assuming similar results to that shown by GCC/LLVM, there is expected to be an average performance hit of 3%, with extreme outliers reaching 17%
• If an end user decides that performance under PAC is unacceptable they should disable PAC at a system level.

Assumption: There is no desire to release two AArch64 Linux versions of OpenJDK - one with PAC protection and one without.

Assumption: Official OpenJDK releases for Linux/AArch64 will be built with GCC version 9.1.0 or newer and branch protection will not be forcibly disabled when building.

Dependencies

Any future PAC work will be dependant on this JEP.