Add support for AArch64 Pointer Authentication ABI in Rust

[asl]

Recently there were efforts in LLVM mainline intended for:

• Backport required pauth ISA and C/C++ pointer authentication ABI bits from Apple downstream forks, including clang frontend bits, something in midend and generic backend things (see https://clang.llvm.org/docs/PointerAuthentication.html)
• Add support for pointer authentication for ELF platforms as specified in https://github.com/ARM-software/abi-aa/blob/main/pauthabielf64/pauthabielf64.rst, both in frontend (via "test" pauthest ABI and LLVM backend).

As a result, LLVM 21 has more or less complete support for pointer authentication features for ELF targets (MachoO bits are still not there, so there is no full arm64e ABI support).

This is a tracking issue to add support for pointer authentication to Rust basing on the existing LLVM support.

Overall, everything could be split into 3 subtasks:

• Add support for extern "C" function pointers. This invokes both calling them via signed function pointers from Rust case as well as providing properly authenticated extern "C" Rust functions to be called from pauth-enabled C code. We'd need to support type-discriminated function pointers here as well, so few bits of signing scheme should be either reimplemented in rustc or imported from elsewhere (e.g. clang). The support should be based on Linux pauthtest ABI and could be further adopted by interested platforms. Overall the pauth itself support seems to be simple, it is just some boilerplate glue code that requires to be written.
• Same as above but for C++ functions. This might be much more elaborated as C++ pointer authentication ABI relies on many implementations details (and could be dependent on the chosen signing scheme)
• Develop pointer authentication ABI for Rust code. This would require development of Rust Pointer Authentication ABI and certainly would require an RFC.

I want to explicitly mention that the primary target would be ELF-based platforms. There is no intention to support arm64e (so this issue is a bit orthogonal to #73628) simply because there is no full LLVM mainline support for this ABI at the time of writing. Still, I'd anticipate that implementing the pauth for ELF platforms would allow straightforward implementation of arm64e ABI if / when LLVM mainline would support it – likely some lightweight plumbing of settings and options.

References:

• https://llvm.org/devmtg/2019-10/slides/McCall-Bougacha-arm64e.pdf
• https://llvm.org/devmtg/2024-10/slides/techtalk/Korobeynikov-Adding-Pointer-Authentication-ABI-support.pdf
• https://github.com/ARM-software/abi-aa/blob/main/pauthabielf64/pauthabielf64.rst
• https://clang.llvm.org/docs/PointerAuthentication.html

[asl]

Tagging @jchlanda

[asl]

And to further clarify the things: we are going to implement at least first two of aforementioned subtasks

[workingjubilee]

@asl Hrm. How do you intend to determine when to use the C vs. C++ variants (assuming I am understanding correctly that they can differ) from Rust code? I believe from Rust's perspective there is only extern "C" and funny-looking extern "C", so the two aren't clearly differentiated.

[davidtwco]

I've renamed this issue to "Pointer Authentication ABI" to distinguish it from the existing Pointer Authentication support tracked in #113369.

[asl]

@asl Hrm. How do you intend to determine when to use the C vs. C++ variants (assuming I am understanding correctly that they can differ) from Rust code? I believe from Rust's perspective there is only extern "C" and funny-looking extern "C", so the two aren't clearly differentiated.

This is something we'd need to figure out & design :) I guess funny-looking extern C will use type discrimination and should be resigned to a proper C++-aware discriminator when "crossing" to C++ world.

[workingjubilee]

I see!

One possible option that requires increased Rust support is to attach an attribute to the declaration of the function... like so:

unsafe extern "C" {
    #[your_paint_choice_here]
    fn something_from_cpp();
}

and teach rust-bindgen to emit that attribute when it is binding C++ code. This would handle a lot of practical uses, I think, since it is common to use it for binding code.

Adding an extern "C++" ABI is another option that offers more direct support and is not technically impossible, but raises a lot of questions that may make it overly costly as a route, depending.

[asl]

and teach rust-bindgen to emit that attribute when it is binding C++ code. This would handle a lot of practical uses, I think, since it is common to use it for binding code.

My immediate thought is to try to support, say, cxx::bridge only and see what changes / plumbing would be required. Likely this would allow us to have C++ bits for free (as there is code generated there and compiled by pauth-aware host compiler).