Add x86_64 Shadow Stack support for Linux

[submachine]

Feature or enhancement

Proposal:

This issue proposes adding Shadow Stack support to cpython builds for x86_64 on Linux.

Shadow Stacks are a hardware-enforced security feature that maintains a separate, tamper proof list of return addresses to protect against Return-Oriented Programming style exploits. Shadow Stack hardware support is available on Intel 11th Generation and newer CPUs, and AMD Zen3 and newer CPUs. It is supported by both GCC (8.1+) and LLVM (7.0.0+) since 2018. On CPUs that do not support this feature, or systems where glibc does not enable it by default, compatible binaries run without any performance cost. As of today, no major Linux distribution enables shadow stack protection by default although some do build packages with support for it.

Fedora has been building its packages with CET support (which includes Shadow Stack, and additionally Indirect Branch Tracking) since 2018, i.e. Fedora 28, and Ubuntu since 24.04.

We are working on enabling Shadow Stack by default in Fedora (https://fedoraproject.org/wiki/Changes/ShadowStack). Once complete, the change would mean that Fedora enforces Shadow Stack protection at runtime for applications that support it.

The proposal is to add -fcf-protection=return (shstk-only, no IBT) to cpython's BASECFLAGS in configure.ac for the x86_64-linux-gnu platform triplet so that the interpreter, stdlib, and third-party extensions built against it are compiled with Shadow Stack support.

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

[picnixz]

I think this should be left to downstream distributors. They can change the CFLAFGS themselves and we want to ensure maximal compatibility for PEP-11 platforms in general.

As observed it is not even something that distributors so I do not think it should be done here. I believe a discuss.python.org thread is required first as well.

[submachine]

@picnixz thank you for looking at this. I will be happy to start a discussion around this on discuss.python.org, but I wanted to address the compatibility concern here: building with shadow-stack support increases compatibility because it makes it possible to run the binaries without or with protection enabled at runtime (as opposed to now, when it's not possible to run with protection enabled). Fedora and Ubuntu already build with the appropriate flag. Fedora does this since 2018. Binaries that support shadow-stack run practically without performance cost and with no compatibility issues on machines that do not support it and runtimes that do not enable it.

I am working on a Fedora change proposal to now enable support at runtime. One of the issues we face is that third-party extensions (which by default inherit flags from here) are not built with protection. This means that if a Fedora application (built with support) starts in shadow-stack mode, dlopen-ing an extension without the SHSTK note causes a runtime error.

Enabling this here will have no negative compatibility effect on the ecosystem as of today while allowing distros the possibility to transition to shadow-stack mode without compatibility issues in the future.

[picnixz]

I am sorry but doesn't it contradict

As of today, no major Linux distribution enables shadow stack protection by default although some do build packages with support for it.

or was this statement for general builds? (maybe I misunderstood). Also does it increase build time? what if users do NOT want this? We could add a configure option but I do not think this should be done by default.

IIRC we did have a discussion about default flags for security such as #112301 and I believe a DPO thread is necessary to avoid the issues and confusion that stemmed from it.

[submachine]

I am sorry but doesn't it contradict

As of today, no major Linux distribution enables shadow stack protection by default although some do build packages with support for it.

or was this statement for general builds? (maybe I misunderstood).

I should definitely have been clearer here. There is a runtime part, and a compile time part:

When enabled, the CPU verifies return addresses on the stack against a protected duplicate copy. No distribution (that I know of) enables the feature at run-time today. For Fedora, we are working on this runtime enablement. But: being able to enable at run-time depends on whether the binaries are built to be compatible. The compatibility is a compile-time decision, and Fedora and Ubuntu already build most of the distribution with the flag enabled. i.e. the binaries are capable of running in shadow-stack mode.

Also does it increase build time?

Since the majority of code (outside of setjmp/longjmp, JIT compilers, etc.) does not manipulate return addresses once stored on the stack, in most cases the only thing that happens when -fcf-protection=return is passed to the compiler is that it emits an ELF note marking the binary as compatible. i.e. the overhead for build-time is negligible.

what if users do NOT want this?

This is a good question. I don't know how we can tackle this, but my only argument is that users can run the shadow-stack compatible binaries unprotected. This is what is happening on Fedora since 2018, i.e. the distribution is built with protection, but runs without it by default.

We could add a configure option but I do not think this should be done by default.

IIRC we did have a discussion about default flags for security such as #112301 and I believe a DPO thread is necessary to avoid the issues and confusion that stemmed from it.

I will start a discussion soon.

Thank you so much for engaging with me here.