All commit authors signed the Contributor License Agreement.

Most changes to Python require a NEWS entry.

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

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

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

@erlend-aasland Looks green 👍🏻

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

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?

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.

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.

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.

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

@pablogsal cc @erlend-aasland
Is this patch will affect trampoline implementation?
Would you like to check the impact please?

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

@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.

🤖 New build scheduled with the buildbot fleet by @pablogsal for commit f08af17 🤖

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

I'm also checking with the buildbot fleet.

From https://lore.kernel.org/linux-arm-kernel/Y1q914IVy6XgE1xq@hirez.programming.kicks-ass.net/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.

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

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

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.

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.