gh-94471: Enable pointer authentication on aarch64 builds

[jgowdy]

ARM64v8.3 supports Pointer Authentication with the PACIASP and AUTIASP instructions which are interpreted as NOP instructions on pre-8.3 architectures. These instructions sign the stack pointer and validate the stack pointer prior to return to mitigate return oriented programming.

GCC supports these options on arm64 / aarch64. The legacy option was -msign-return-address=[all | non-leaf | none] and the modern option is -mbranch-protection=none|standard|pac-ret[+leaf+b-key]|bti

I would like to suggest that the arm64 build be modified to include -mbranch-protection=pac-ret with the -march being set to ARMv8.2 or earlier or not configured, so that GCC will generate PACIASP and AUTIASP instructions. It is critical that -march=armv8.3 or higher not be passed or the non-backwards compatible RETAA instruction will be generated.

The benefit of enabling pointer authentication for the stack pointer on ARM64 would be to mitigate return oriented programming attacks against the CPython runtime.

Presently we (GoDaddy) are pursuing custom compiles of the CPython runtime for the new Graviton3 CPUs that support pointer authentication in AWS.

• Issue: gh-94471

[cpython-cla-bot[bot]]

All commit authors signed the Contributor License Agreement.

[bedevere-bot]

Most changes to Python require a NEWS entry.

Please add it using the blurb_it web app or the blurb command-line tool.

[jgowdy]

I'll need to regenerate configure with the appropriate version of autoconf

[erlend-aasland]

I'll need to regenerate configure with the appropriate version of autoconf

docker run --rm --pull=always -v"$PWD:/src" http://quay.io/tiran/cpython_autoconf:269

[jgowdy]

@erlend-aasland Looks green 👍🏻

[jgowdy]

I've attempted to simplify the M4sh here to only need AS_CASE and AX_CHECK_COMPILE_FLAG. Is this suitable?

[erlend-aasland]

Thanks. The AC change looks good to me. I have no opinions regarding the arch specifics here. Perhaps @corona10 or @tiran can chime in for that?

[tiran]

Are there potential performance issues or backwards compatibility issues with -mbranch-protection?

-msign-return-address is a legacy option. It looks like GCC 9 and newer have -mbranch-protection. GCC 9 or newer are available for most distros, even RHEL 7 with DevTool set.

[jgowdy]

Are there potential performance issues or backwards compatibility issues with -mbranch-protection?

There is a minor performance impact related to the CPU calculating the signed pointer, but it's on the order of the CPU doing math in hardware.

-msign-return-address is a legacy option. It looks like GCC 9 and newer have -mbranch-protection. GCC 9 or newer are available for most distros, even RHEL 7 with DevTool set.

Yes, sign-return-address is a legacy option. Do you think we need to exclude the legacy option? I included it for completeness.

[jgowdy]

Are there potential performance issues or backwards compatibility issues with -mbranch-protection?

I should have also stated, there isn't a backwards compatibility issue here since the instructions are implemented in the NOP space for prior architectures.

[corona10]

@erlend-aasland I will take a look at this PR, I may need to understand potential impact with this patch :)

[corona10]

@pablogsal cc @erlend-aasland Is this patch will affect trampoline implementation? Would you like to check the impact please? https://github.com/python/cpython/blob/1f737edb67e702095feb97118a911afb569f5705/Python/asm_trampoline.S#L17-L25

@jgowdy Would you like to submit the pyperformance benchmark result comparing the result between non-pointer authentication and pointer authentication?

[pablogsal]

@pablogsal cc @erlend-aasland

Is this patch will affect trampoline implementation?

It has potential to, specifically it may affect unwinders (including perf), debuggers and state inspection tools. We should check if the main unwinders know how to handle these pointers correctly.

[bedevere-bot]

:robot: New build scheduled with the buildbot fleet by @pablogsal for commit f08af17f9cbde3801214787f63736813c202edd7 :robot:

If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again.

[pablogsal]

I'm also checking with the buildbot fleet.

[pablogsal]

From https://lore.kernel.org/linux-arm-kernel/[email protected]/t/ :

Perf report cannot produce callgraphs using dwarf on arm64 where pointer authentication is enabled. This is because libunwind and libdw cannot unmangle instruction pointers that have a pointer authentication code (PAC) embedded in them. libunwind and libdw need to be given an instruction mask which they can use to arrive at the correct return address that does not contain the PAC.

I think, if confirmed, this is a significant enough drawback that makes this a big blocker for merging this and having it active by default.

It seems that someone is working on this but this email chain is very recent so I doubt most perf/libunwind versions out there will know how to handle it.

In any case, we should run our own experiments to see how this affects these tools.

[erlend-aasland]

Thanks, Dong-hee and Pablo! I'll mark this as do-not-merge, just to be on the safe side.

[pablogsal]

This makes test_gdb fail on aarch64 RHEL buildbots, so this more or less confirms that this messes up with debuggers as I suspected.

[erlend-aasland]

Given Dong-hee's and Pablo's valuable input on this, I believe we can conclude with that this feature is not something we can easily implement. Suggesting to close this PR and the linked issue.

[pablogsal]

Agreed, also this is something that redistributors can easily do by setting CFLAGS or similar on they custom builds if they are ok sacrificing debugging / profilings capabilities.