Wiki - https://fedoraproject.org/wiki/Changes/ShadowStack Discussion thread - https://discussion.fedoraproject.org/t/f45-change-proposal-enable-shadow-sta...
This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == This change enables Shadow Stack protection on applications and libraries built with gcc (C, C++), clang (C, C++), and rustc (Rust) by default on x86_64 machines that support it on Fedora Linux 45. The dynamic linker or static startup routines will activate Shadow Stack for any process whose binary and shared library dependencies are all built with Shadow Stack support (marked with ELF metadata), protecting processes by default whenever possible.
== Owner == * Name: [[User:submachine| Arjun Shankar]] * Email: arjun@redhat.com
== Detailed Description == 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. This change enables Shadow Stack protection by default on x86_64 machines that support it on Fedora Linux 45. The dynamic linker, or static startup routines, will activate Shadow Stack for any process whose binary and shared library dependencies are all built with Shadow Stack support, protecting processes by default whenever possible. Shadow Stacks are one of two Control-Flow Enforcement features introduced in Intel CET, alongside Indirect Branch Tracking (IBT), designed to defend against Return-Oriented Programming (ROP) and Jump-Oriented Programming (JOP) attacks by protecting return addresses. This Fedora change only covers enabling Shadow Stack support. Enabling Indirect Branch Tracking by default is not in scope.
This change is backward compatible for the most part: `-fcf-protection` is a default compile time flag already enabled in `redhat-rpm-config` for Fedora since 2018 and thus the majority of binaries are already built with the appropriate markup. Thus, after this change is applied, applications whose dependencies carry Shadow Stack markup gain protection transparently while applications that load any non-compliant object at startup continue to run without Shadow Stack protection. The only new failure mode is when a Shadow Stack enabled process attempts to `dlopen` a non-compliant shared object at runtime, which results in a `dlopen` error that looks like `error: dlopen: /path/to/library.so: rebuild shared object with SHSTK support enabled`.
Two mitigation strategies can be used, depending on the package:
# Where the `dlopen`ed library can be fixed to include Shadow Stack support, the library is fixed and rebuilt with the appropriate markup. This is the preferred fix because it preserves Shadow Stack protection for the calling application. # Where the non-compliant code cannot be fixed in time, the calling application is opted out of Shadow Stack via glibc's [https://inbox.sourceware.org/libc-alpha/cover.1782444639.git.dj@redhat.com/T... System-Wide Tunables] configuration that can be shipped per-application as a configuration file. This disables Shadow Stack for that specific application while all other processes retain protection.
== Feedback == No community feedback has been received yet. This section will be updated as feedback is collected.
== Benefit to Fedora == This change provides hardware-enforced protection against Return-Oriented Programming (ROP) style attacks for the majority of Fedora binaries at negligible performance cost.
Shadow Stacks are enforced by the CPU and do not require software instrumentation at runtime. The overhead is limited to maintaining a second copy of the return address stack in protected memory, which has no measurable impact on typical workloads.
The change is transparent: compliant applications are protected without any code change, rebuild, or user action. Because `-fcf-protection` is already a default compile flag in Fedora, the majority of packages are already built with the appropriate ELF markup. Enabling Shadow Stack in the dynamic linker activates protection for these packages immediately.
This also lays groundwork for enabling Indirect Branch Tracking (IBT) in a future release, which together with Shadow Stack would provide full Control-Flow Enforcement Technology (CET) protection.
== Scope == * Proposal owners: The glibc maintainers will: # Apply a glibc downstream patch that reverts an upstream change that deactivates Shadow Stack support. # Include the upstream glibc [https://inbox.sourceware.org/libc-alpha/cover.1782444639.git.dj@redhat.com/T... System-Wide Tunables] feature, which has obtained upstream consensus and will be part of the next glibc release. This feature enables per-application opt-out via configuration files. # Ship `/etc/tunables.conf` with `include /etc/tunables.conf.d/*.conf` so that individual packages can drop in their own configuration files in order to opt-out. # Validate that SUID/SGID applications correctly sanitize tunables so that unprivileged users cannot disable Shadow Stack for privileged programs. # Open tracking bugs for all known incompatible packages.
* Other developers: Most packages built with Fedora's default flags already produce Shadow Stack compatible binaries and no action is needed in this case. Packages that include hand-written assembly or build with different flags might ship ELF objects without Shadow Stack markup. Maintainers of such packages will need to make changes to their package to include Shadow Stack markup (e.g., annotate assembly routines).
A special case is applications built with Shadow Stack support that currently `dlopen` shared objects built without it. These applications will encounter a runtime error at `dlopen` unless one of these fixes is applied:
# The `dlopen`ed library is compiled with Shadow Stack support enabled. # The application opts out of Shadow Stack support using glibc's System-Wide Tunables feature. For example, a package named `app` providing `/usr/bin/app` would install `/etc/tunables.conf.d/app.conf` containing:
<pre> [proc:/usr/bin/app] glibc.cpu.x86_shstk=off </pre>
This disables Shadow Stack for that specific application while all other processes retain protection. The drop-in file is owned by the affected package's RPM, so it is added and removed with the package. Once the dependency is fixed, the package update removes the drop-in file and the application gains Shadow Stack protection.
* Release engineering: [https://forge.fedoraproject.org/releng/tickets/issues/13388 #13388] Most objects are already built with support, and enablement is via a glibc update. For Rust, binary packages need to be rebuilt once the Rust dependency is in place. This can be done as part of the regularly scheduled Fedora 45 mass-rebuild. We will track this as part of the F45 GNU Toolchain release engineering ticket linked to above.
* Policies and guidelines: No changes to packaging guidelines are required at this time. Default build configuration already builds objects with support and for the majority of packages, the change is transparent.
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: This change is in line with Fedora's security posture and commitment to shipping secure-by-default systems.
== Upgrade/compatibility impact == After upgrading to Fedora 45, Shadow Stack support will be enabled automatically for processes whose binary and all loaded shared libraries carry the appropriate markup. Processes that load any non-compliant shared object will have Shadow Stack silently disabled at startup.
The only exception is applications that are fully Shadow Stack compliant at startup and then use `dlopen` to load a shared object without Shadow Stack markup at runtime. This will lead to a `dlopen` failure. However, affected applications can be configured to opt out of Shadow Stack protection, or have their dependencies fixed. Incompatible packages will be identified by scanning the Fedora package set for ELF objects missing the SHSTK property note, and by testing critical desktop and server workloads against the COPR repository with Shadow Stack enabled. Tracking bugs will be filed for all known incompatible packages. This work has already started and is being tracked in [https://bugzilla.redhat.com/show_bug.cgi?id=2458434 Bugzilla].
# Where the `dlopen`ed library is under Fedora's control, it can either be fixed and rebuilt with support, or the dependent package configured to run with Shadow Stack turned off as described in the Scope section above. # Users who encounter this problem with third party applications can work around it using the System-Wide Tunables feature as described earlier.
== Early Testing (Optional) == A COPR repository with the updated glibc (Shadow Stack enabled) is available for Fedora 43, 44, and Rawhide for early testing: https://copr.fedorainfracloud.org/coprs/submachine/glibc-x86_64-SHSTK-Testin...
Do you require 'QA Blueprint' support? No <!-- Optional Step for System-Wide Changes only -->
== How To Test == 1. Shadow Stack hardware support is available on Intel 11th Generation and newer CPUs, and AMD Zen3 and newer CPUs, so testing does not require any special hardware except a recent enough x86_64 processor.
2. Machine learning workloads that use GPU acceleration via AMD ROCm are a specific area of interest because the ROCm runtime libraries may lack Shadow Stack markup. Testing these workloads (e.g., pytorch with ROCm) requires access to AMD GPUs.
3. Once the runtime has been enabled for Shadow Stack, testing involves (a) verifying the shadow stack status of running processes (`cat /proc/$pid/status | grep x86_Thread_features`), and (b) verifying that there are no application errors or crashes due to incompatible binaries.
4. The majority of running processes should be protected, with Shadow Stack enabled.
== User Experience == This change is transparent to users. No action is required to enable or configure support. Applications that are not compatible with Shadow Stack run without the protection; they continue to function normally but do not benefit from the additional security. In rare cases, an application that loads a non-compliant plugin at runtime may encounter a `dlopen` error. Known affected applications ship with a drop-in configuration file that prevents this. Users who encounter this with other applications can create a file in `/etc/tunables.conf.d/` to opt the application out, and then run `ldconfig`.
== Dependencies == 1. Rust: The rust compiler needs to be able to generate Shadow Stack compatible binaries. This affects a significant part of the Fedora runtime and applications, including `rpm` and `firefox`. However, we are collaborating with the Rust team and have already tested a `rustc` change that enables emitting compatible binaries by default (without the use of any flags). The [https://bugzilla.redhat.com/show_bug.cgi?id=2196282 Rust Fedora Bug] tracks this.
2. Firefox and Chrome: Both browsers are currently not compatible with Shadow Stack although the Firefox binary and some objects are built with Shadow Stack enabled. Upstream work, in particular around their JIT compilers, as well as the rust tooling change mentioned above are needed in order to fix this. Until then, we propose to disable Shadow Stack protection flags when building Firefox. Both browsers will gain Shadow Stack protection once their upstream dependencies are resolved, at which point they can be rebuilt with protection turned on.
== Contingency Plan == * Contingency mechanism: Downstream patch applied to glibc to enable Shadow Stacks by default in Fedora will be reverted. * Contingency deadline: No deadline. The patch can be reverted as late as necessary in the development cycle. * Blocks release? No.
== Documentation ==
=== Guide for package maintainers ===
==== Checking an ELF object for CET support ====
Use `readelf` to inspect the GNU property note on any object file, shared library, or binary. e.g.:
<pre> readelf -n /usr/lib64/libc.so.6 | grep 'IBT|SHSTK' </pre>
A fully compliant object shows both properties:
<pre> Properties: x86 feature: IBT, SHSTK </pre>
While this change only requires `SHSTK`, IBT (Indirect Branch Tracking) will be enabled in a future release and fixing both now avoids having to revisit these packages later. For this change, only `SHSTK` is required. An object with `IBT` but not `SHSTK` will still cause Shadow Stack to be disabled for the process. An object with `SHSTK` but not `IBT` is fully compliant with this change. Fixing both properties is recommended so that packages are ready for a future IBT enablement, but only `SHSTK` is needed now. The linker ANDs these bits across all inputs, so a single unmarked object will strip the property from the final binary. Packages are built by default with `-fcf-protection` enabled, so source files when compiled with default flags are automatically built with SHSTK/IBT support. However, hand-written assembly needs annotations in order to be built with the property enabled. This leads to situations where linking against objects built with hand-written assembly without the appropriate annotations strips the final binary or shared object of CET support.
==== Annotating a GAS assembly file ====
Hand-written `.S` files compiled through GCC do not automatically receive the CET property note. To fix this, add one line near the top of the file:
<pre> #include <cet.h> </pre>
For IBT compatibility, add `_CET_ENDBR` (also defined by `cet.h`) at the entry point of any function that may be reached via an indirect branch (e.g. function pointer):
<pre> #include <cet.h>
.text .globl my_handwritten_func .type my_handwritten_func, @function my_handwritten_func: _CET_ENDBR /* ..function body */ ret </pre>
== Release Notes ==
On Wed, Jul 01, 2026 at 05:10:00PM +0100, Aoife Moloney via devel-announce wrote:
Wiki - https://fedoraproject.org/wiki/Changes/ShadowStack Discussion thread - https://discussion.fedoraproject.org/t/f45-change-proposal-enable-shadow-sta...
This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == This change enables Shadow Stack protection on applications and libraries built with gcc (C, C++), clang (C, C++), and rustc (Rust) by default on x86_64 machines that support it on Fedora Linux 45. The dynamic linker or static startup routines will activate Shadow Stack for any process whose binary and shared library dependencies are all built with Shadow Stack support (marked with ELF metadata), protecting processes by default whenever possible.
snip
This change is backward compatible for the most part: `-fcf-protection` is a default compile time flag already enabled in `redhat-rpm-config` for Fedora since 2018 and thus the majority of binaries are already built with the appropriate markup. Thus, after this change is applied, applications whose dependencies carry Shadow Stack markup gain protection transparently while applications that load any non-compliant object at startup continue to run without Shadow Stack protection. The only new failure mode is when a Shadow Stack enabled process attempts to `dlopen` a non-compliant shared object at runtime, which results in a `dlopen` error that looks like `error: dlopen: /path/to/library.so: rebuild shared object with SHSTK support enabled`.
Two mitigation strategies can be used, depending on the package:
# Where the `dlopen`ed library can be fixed to include Shadow Stack support, the library is fixed and rebuilt with the appropriate markup. This is the preferred fix because it preserves Shadow Stack protection for the calling application. # Where the non-compliant code cannot be fixed in time, the calling application is opted out of Shadow Stack via glibc's [https://inbox.sourceware.org/libc-alpha/cover.1782444639.git.dj@redhat.com/T... System-Wide Tunables] configuration that can be shipped per-application as a configuration file. This disables Shadow Stack for that specific application while all other processes retain protection.
It sounds like the biggest risk of problems will arise from apps with plugins, where there is a common use of closed source or non-Fedora distributed binaries.
Does NVIDIA still want its own libGL and if so, is that built with shadow stack support ? If not, then presumably every desktop app would need to opt out ? A per-binary opt-name feels non-scalable for that scenario
Also I wonder if there are any gstreamer plugins (from non-Fedora repos) that might cause trouble here and similarly impact a wide range of apps ?
With regards, Daniel
On Wed, Jul 1, 2026 at 4:41 PM Daniel P. Berrangé berrange@redhat.com wrote:
It sounds like the biggest risk of problems will arise from apps with plugins, where there is a common use of closed source or non-Fedora distributed binaries.
Does NVIDIA still want its own libGL and if so, is that built with shadow stack support ? If not, then presumably every desktop app would need to opt out ? A per-binary opt-name feels non-scalable for that scenario
Last I recall (I have not checked recently) the NVIDIA cuda libs did not have shadow stack support, so all the solutions that use dlopen for dynamic use of the cuda frameworks are going to have issues (and that may include a number of things like PyTorch or TensorFlow).
Last I recall (I have not checked recently) the NVIDIA cuda libs did not have shadow stack support, so all the solutions that use dlopen for dynamic use of the cuda frameworks are going to have issues (and that may include a number of things like PyTorch or TensorFlow).
We already have a ticket in place specifically to test PyTorch with Nvidia and AMD GPUs. How should we test TensorFlow? I have no experience with it.
It sounds like the biggest risk of problems will arise from apps with plugins, where there is a common use of closed source or non-Fedora distributed binaries.
Does NVIDIA still want its own libGL and if so, is that built with shadow stack support ? If not, then presumably every desktop app would need to opt out ? A per-binary opt-name feels non-scalable for that scenario
Also I wonder if there are any gstreamer plugins (from non-Fedora repos) that might cause trouble here and similarly impact a wide range of apps ?
About Nvidia, I did not mention it in the change proposal because Fedora doesn't ship their drivers. However, we do have a ticket filed for testing with Nvidia.
On Wed, Jul 1, 2026 at 6:11 PM Aoife Moloney via devel-announce < devel-announce@lists.fedoraproject.org> wrote:
Wiki - https://fedoraproject.org/wiki/Changes/ShadowStack Discussion thread -
https://discussion.fedoraproject.org/t/f45-change-proposal-enable-shadow-sta...
== Summary == This change enables Shadow Stack protection on applications and libraries built with gcc (C, C++), clang (C, C++), and rustc (Rust) by default on x86_64 machines that support it on Fedora Linux 45. The dynamic linker or static startup routines will activate Shadow Stack for any process whose binary and shared library dependencies are all built with Shadow Stack support (marked with ELF metadata), protecting processes by default whenever possible.
== Detailed Description == 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. This change enables Shadow Stack protection by default on x86_64 machines that support it on Fedora Linux 45. The dynamic linker, or static startup routines, will activate Shadow Stack for any process whose binary and shared library dependencies are all built with Shadow Stack support, protecting processes by default whenever possible. Shadow Stacks are one of two Control-Flow Enforcement features introduced in Intel CET, alongside Indirect Branch Tracking (IBT), designed to defend against Return-Oriented Programming (ROP) and Jump-Oriented Programming (JOP) attacks by protecting return addresses. This Fedora change only covers enabling Shadow Stack support. Enabling Indirect Branch Tracking by default is not in scope.
This change is backward compatible for the most part: `-fcf-protection` is a default compile time flag already enabled in `redhat-rpm-config` for Fedora since 2018 and thus the majority of binaries are already built with the appropriate markup. Thus, after this change is applied, applications whose dependencies carry Shadow Stack markup gain protection transparently while applications that load any non-compliant object at startup continue to run without Shadow Stack protection. The only new failure mode is when a Shadow Stack enabled process attempts to `dlopen` a non-compliant shared object at runtime, which results in a `dlopen` error that looks like `error: dlopen: /path/to/library.so: rebuild shared object with SHSTK support enabled`.
Two mitigation strategies can be used, depending on the package:
# Where the `dlopen`ed library can be fixed to include Shadow Stack support, the library is fixed and rebuilt with the appropriate markup. This is the preferred fix because it preserves Shadow Stack protection for the calling application. # Where the non-compliant code cannot be fixed in time, the calling application is opted out of Shadow Stack via glibc's [ https://inbox.sourceware.org/libc-alpha/cover.1782444639.git.dj@redhat.com/T... System-Wide https://inbox.sourceware.org/libc-alpha/cover.1782444639.git.dj@redhat.com/T/#uSystem-Wide Tunables] configuration that can be shipped per-application as a configuration file. This disables Shadow Stack for that specific application while all other processes retain protection.
== Feedback == No community feedback has been received yet. This section will be updated as feedback is collected.
== Benefit to Fedora == This change provides hardware-enforced protection against Return-Oriented Programming (ROP) style attacks for the majority of Fedora binaries at negligible performance cost.
Shadow Stacks are enforced by the CPU and do not require software instrumentation at runtime. The overhead is limited to maintaining a second copy of the return address stack in protected memory, which has no measurable impact on typical workloads.
The change is transparent: compliant applications are protected without any code change, rebuild, or user action. Because `-fcf-protection` is already a default compile flag in Fedora, the majority of packages are already built with the appropriate ELF markup. Enabling Shadow Stack in the dynamic linker activates protection for these packages immediately.
This also lays groundwork for enabling Indirect Branch Tracking (IBT) in a future release, which together with Shadow Stack would provide full Control-Flow Enforcement Technology (CET) protection.
== Scope ==
- Other developers:
Most packages built with Fedora's default flags already produce Shadow Stack compatible binaries and no action is needed in this case. Packages that include hand-written assembly or build with different flags might ship ELF objects without Shadow Stack markup. Maintainers of such packages will need to make changes to their package to include Shadow Stack markup (e.g., annotate assembly routines).
A special case is applications built with Shadow Stack support that currently `dlopen` shared objects built without it. These applications will encounter a runtime error at `dlopen` unless one of these fixes is applied:
# The `dlopen`ed library is compiled with Shadow Stack support enabled. # The application opts out of Shadow Stack support using glibc's System-Wide Tunables feature. For example, a package named `app` providing `/usr/bin/app` would install `/etc/tunables.conf.d/app.conf` containing:
<pre> [proc:/usr/bin/app] glibc.cpu.x86_shstk=off </pre>
This disables Shadow Stack for that specific application while all other processes retain protection. The drop-in file is owned by the affected package's RPM, so it is added and removed with the package. Once the dependency is fixed, the package update removes the drop-in file and the application gains Shadow Stack protection.
From an OpenSSL perspective, it looks suspicious to me. We have a lot of hand-written assembly. Additionally, OpenSSL provider model would require building 3rd-party providers with Shadow Stack protection, which will break backward compatibility (currently providers built for OpenSSL 3 work with OpenSSL 4).
From an OpenSSL perspective, it looks suspicious to me. We have a lot of hand-written assembly. Additionally, OpenSSL provider model would require building 3rd-party providers with Shadow Stack protection, which will break backward compatibility (currently providers built for OpenSSL 3 work with OpenSSL 4).
annocheck has been flagging missing SHSTK support since RHEL-8, so all openssl incompatibilities should have been fixed by now.
When it comes to common providers, on an F44 box, I see:
/usr/lib64/ossl-modules/fips.so Properties: x86 feature: IBT, SHSTK /usr/lib64/ossl-modules/legacy.so Properties: x86 feature: IBT, SHSTK /usr/lib64/ossl-modules/pkcs11.so Properties: x86 feature: IBT, SHSTK /usr/lib64/ossl-modules/pkcs11sign.so Properties: x86 feature: IBT, SHSTK /usr/lib64/ossl-modules/tpm2.so Properties: x86 feature: IBT, SHSTK
Wiki - https://fedoraproject.org/wiki/Changes/ShadowStack # The `dlopen`ed library is compiled with Shadow Stack support enabled. # The application opts out of Shadow Stack support using glibc's System-Wide Tunables feature. For example, a package named `app` providing `/usr/bin/app` would install `/etc/tunables.conf.d/app.conf`
Please, please, please, make that /usr/lib/tunables.conf.d/app.conf by default. As described below, this is clearly something that is part of the rpm and not "local configuration".
An override in /etc is fine of course.
This disables Shadow Stack for that specific application while all other processes retain protection. The drop-in file is owned by the affected package's RPM, so it is added and removed with the package. Once the dependency is fixed, the package update removes the drop-in file and the application gains Shadow Stack protection.
Zbyszek
On Wed, Jul 1, 2026 at 3:59 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
Wiki - https://fedoraproject.org/wiki/Changes/ShadowStack # The `dlopen`ed library is compiled with Shadow Stack support enabled. # The application opts out of Shadow Stack support using glibc's System-Wide Tunables feature. For example, a package named `app` providing `/usr/bin/app` would install `/etc/tunables.conf.d/app.conf`
Please, please, please, make that /usr/lib/tunables.conf.d/app.conf by default. As described below, this is clearly something that is part of the rpm and not "local configuration".
I don't think this path exists. That's a glibc thing, I think, and the doc about it doesn't indicate any hermetic /usr support.
https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=manual/tunables.texi;h=...
On Wed, Jul 01, 2026 at 04:12:03PM -0400, Neal Gompa wrote:
On Wed, Jul 1, 2026 at 3:59 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
Wiki - https://fedoraproject.org/wiki/Changes/ShadowStack # The `dlopen`ed library is compiled with Shadow Stack support enabled. # The application opts out of Shadow Stack support using glibc's System-Wide Tunables feature. For example, a package named `app` providing `/usr/bin/app` would install `/etc/tunables.conf.d/app.conf`
Please, please, please, make that /usr/lib/tunables.conf.d/app.conf by default. As described below, this is clearly something that is part of the rpm and not "local configuration".
I don't think this path exists. That's a glibc thing, I think, and the doc about it doesn't indicate any hermetic /usr support.
https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=manual/tunables.texi;h=...
Hmm, lack of support for the /usr-/etc split in new code in 2026 is … disappointing.
Zbyszek
* Zbigniew Jędrzejewski-Szmek:
On Wed, Jul 01, 2026 at 04:12:03PM -0400, Neal Gompa wrote:
On Wed, Jul 1, 2026 at 3:59 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
Wiki - https://fedoraproject.org/wiki/Changes/ShadowStack # The `dlopen`ed library is compiled with Shadow Stack support enabled. # The application opts out of Shadow Stack support using glibc's System-Wide Tunables feature. For example, a package named `app` providing `/usr/bin/app` would install `/etc/tunables.conf.d/app.conf`
Please, please, please, make that /usr/lib/tunables.conf.d/app.conf by default. As described below, this is clearly something that is part of the rpm and not "local configuration".
I don't think this path exists. That's a glibc thing, I think, and the doc about it doesn't indicate any hermetic /usr support.
https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=manual/tunables.texi;h=...
Hmm, lack of support for the /usr-/etc split in new code in 2026 is … disappointing.
We can still change it. I suggested that we re-use /etc/ld.so.conf for the tunables settings. Then
Bug 2440274 - Source ld.so configs drop-ins from /usr/lib https://bugzilla.redhat.com/show_bug.cgi?id=2440274
would cover everything. But it was a minority viewpoint at the time of patch review.
Thanks, Florian
On Fri, Jul 03, 2026 at 01:39:07PM +0200, Florian Weimer wrote:
- Zbigniew Jędrzejewski-Szmek:
On Wed, Jul 01, 2026 at 04:12:03PM -0400, Neal Gompa wrote:
On Wed, Jul 1, 2026 at 3:59 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
Wiki - https://fedoraproject.org/wiki/Changes/ShadowStack # The `dlopen`ed library is compiled with Shadow Stack support enabled. # The application opts out of Shadow Stack support using glibc's System-Wide Tunables feature. For example, a package named `app` providing `/usr/bin/app` would install `/etc/tunables.conf.d/app.conf`
Please, please, please, make that /usr/lib/tunables.conf.d/app.conf by default. As described below, this is clearly something that is part of the rpm and not "local configuration".
I don't think this path exists. That's a glibc thing, I think, and the doc about it doesn't indicate any hermetic /usr support.
https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=manual/tunables.texi;h=...
Hmm, lack of support for the /usr-/etc split in new code in 2026 is … disappointing.
We can still change it. I suggested that we re-use /etc/ld.so.conf for the tunables settings. Then
Bug 2440274 - Source ld.so configs drop-ins from /usr/lib https://bugzilla.redhat.com/show_bug.cgi?id=2440274
would cover everything. But it was a minority viewpoint at the time of patch review.
I don't have a strong opinion whether ld.so.conf and tunables.conf should be separate… But I'll say that when I first saw '/etc/tunables.d', I had the thought that the name is quite generic. Reusing /etc/ld.so.conf for the tunables would have the advantage that people would immediately know that it is about the linker…
Zbyszek
Please, please, please, make that /usr/lib/tunables.conf.d/app.conf by default. As described below, this is clearly something that is part of the rpm and not "local configuration".
I don't think this path exists. That's a glibc thing, I think, and the doc about it doesn't indicate any hermetic /usr support.
https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=manual/tunables.texi;h=...
Upstream doesn't need to support multiple configuration directories. An appropriate "include" line in the configuration shipped by Fedora's glibc can solve this. We intend to ship appropriate configuration to allow drop-in files, and the /usr/lib route suggested earlier in this thread sounds like a reasonable one.
On Fri, Jul 3, 2026 at 11:51 AM Arjun Shankar arjun@redhat.com wrote:
Please, please, please, make that /usr/lib/tunables.conf.d/app.conf by default. As described below, this is clearly something that is part of the rpm and not "local configuration".
I don't think this path exists. That's a glibc thing, I think, and the doc about it doesn't indicate any hermetic /usr support.
https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=manual/tunables.texi;h=...
Upstream doesn't need to support multiple configuration directories. An appropriate "include" line in the configuration shipped by Fedora's glibc can solve this. We intend to ship appropriate configuration to allow drop-in files, and the /usr/lib route suggested earlier in this thread sounds like a reasonable one.
Requiring /etc files to load /usr files violates the principle. It needs to work the other way around.
On Fri, Jul 03, 2026 at 11:53:02AM -0400, Neal Gompa wrote:
On Fri, Jul 3, 2026 at 11:51 AM Arjun Shankar arjun@redhat.com wrote:
Please, please, please, make that /usr/lib/tunables.conf.d/app.conf by default. As described below, this is clearly something that is part of the rpm and not "local configuration".
I don't think this path exists. That's a glibc thing, I think, and the doc about it doesn't indicate any hermetic /usr support.
https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=manual/tunables.texi;h=...
Upstream doesn't need to support multiple configuration directories. An appropriate "include" line in the configuration shipped by Fedora's glibc can solve this. We intend to ship appropriate configuration to allow drop-in files, and the /usr/lib route suggested earlier in this thread sounds like a reasonable one.
Requiring /etc files to load /usr files violates the principle. It needs to work the other way around.
"violates" is maybe a tad too strong. But it'd be great if this file was not needed at all. A config file to configure the standard location of other config files feels … superfluous.
Zbyszek
# The application opts out of Shadow Stack support using glibc's System-Wide Tunables feature. For example, a package named `app` providing `/usr/bin/app` would install `/etc/tunables.conf.d/app.conf`
Please, please, please, make that /usr/lib/tunables.conf.d/app.conf by default. As described below, this is clearly something that is part of the rpm and not "local configuration".
An override in /etc is fine of course.
We can add “include /usr/lib/tunables.conf.d/*.conf” as well. This is simply a matter of glibc packaging.
On 01/07/2026 18:10, Aoife Moloney via devel-announce wrote:
This change enables Shadow Stack protection on applications and libraries built with gcc (C, C++), clang (C, C++), and rustc (Rust) by default on x86_64 machines that support it on Fedora Linux 45. The dynamic linker or static startup routines will activate Shadow Stack for any process whose binary and shared library dependencies are all built with Shadow Stack support (marked with ELF metadata), protecting processes by default whenever possible.
Have you done any comparative analysis of the performance impact of this change?
The only exception is applications that are fully Shadow Stack compliant at startup and then use `dlopen` to load a shared object without Shadow Stack markup at runtime. This will lead to a `dlopen` failure.
It looks like it can break NVIDIA cuda/drivers, Steam and other proprietary applications, and third-party FOSS builds.
- Shadow Stack hardware support is available on Intel 11th Generation
and newer CPUs, and AMD Zen3 and newer CPUs, so testing does not require any special hardware except a recent enough x86_64 processor.
What about older CPUs?
Have you done any comparative analysis of the performance impact of this change?
We expect the impact to be low since this is a CPU feature. However, we do plan to conduct performance testing.
The only exception is applications that are fully Shadow Stack compliant at startup and then use `dlopen` to load a shared object without Shadow Stack markup at runtime. This will lead to a `dlopen` failure.
It looks like it can break NVIDIA cuda/drivers, Steam and other proprietary applications, and third-party FOSS builds.
We are exploring other compatibility mechanisms, particularly for programs that are still single-threaded when they start dlopen'ing. But there is certainly a compatibility cost.
- Shadow Stack hardware support is available on Intel 11th Generation
and newer CPUs, and AMD Zen3 and newer CPUs, so testing does not require any special hardware except a recent enough x86_64 processor.
What about older CPUs?
Execution on older CPUs without Shadow Stack support is completely unaffected in any way. Fedora has been building and shipping SHSTK enabled binaries since 2018.
On 03/07/2026 18:11, Arjun Shankar wrote:
We expect the impact to be low since this is a CPU feature. However, we do plan to conduct performance testing.
This had to be done before the proposal was published for voting.
We are exploring other compatibility mechanisms, particularly for programs that are still single-threaded when they start dlopen'ing. But there is certainly a compatibility cost.
If this results in breaking NVIDIA drivers and other important third-party software, then this is absolutely unacceptable.
Execution on older CPUs without Shadow Stack support is completely unaffected in any way.
Any performance impact on these old CPUs?
On Saturday, 4 July 2026 12:23:40 Central European Summer Time Vitaly Zaitsev via devel wrote:
If this results in breaking NVIDIA drivers and other important third-party software, then this is absolutely unacceptable.
This proposal will not affect kernel drivers since it only changes the system's behaviour in user mode. Kernel mode will remain unchanged.
The primary concerns regarding third-party user-level software are: 1. applications that claim to be compliant but are not, 2. non-compliant third-party plugins for compliant applications.
The 'tunables' mechanism described in the proposal can be used to work around both. Some system knowledge (and `root` privileges) are needed for creating a corresponding configuration file.
Notably, applications that do not falsely claim compliance will just keep working.
Any performance impact on these old CPUs?
None at all.
Best regards, Christoph
On Wed, Jul 01, 2026 at 05:10:00PM +0100, Aoife Moloney via devel-announce wrote:
...
Two mitigation strategies can be used, depending on the package:
# Where the `dlopen`ed library can be fixed to include Shadow Stack support, the library is fixed and rebuilt with the appropriate markup. This is the preferred fix because it preserves Shadow Stack protection for the calling application. # Where the non-compliant code cannot be fixed in time, the calling application is opted out of Shadow Stack via glibc's [https://inbox.sourceware.org/libc-alpha/cover.1782444639.git.dj@redhat.com/T... System-Wide Tunables] configuration that can be shipped per-application as a configuration file. This disables Shadow Stack for that specific application while all other processes retain protection.
Related to the "what about binary plugins" problem that others have raised, can this be set through the usual environment variable instead of having to use a file? eg.
export GLIBC_TUNABLES=glibc.cpu.x86_shstk=off
Rich.
On Thu, Jul 2, 2026 at 1:11 PM Richard W.M. Jones rjones@redhat.com wrote:
Related to the "what about binary plugins" problem that others have raised, can this be set through the usual environment variable instead of having to use a file? eg.
export GLIBC_TUNABLES=glibc.cpu.x86_shstk=off
Yes, this is still possible.
On Fri, Jul 03, 2026 at 06:15:23PM +0200, Arjun Shankar wrote:
On Thu, Jul 2, 2026 at 1:11 PM Richard W.M. Jones rjones@redhat.com wrote:
Related to the "what about binary plugins" problem that others have raised, can this be set through the usual environment variable instead of having to use a file? eg.
export GLIBC_TUNABLES=glibc.cpu.x86_shstk=off
Yes, this is still possible.
Thanks - this seems much more convenient than the file, at least for some situations.
Rich.
On Wed, Jul 01, 2026 at 05:10:00PM +0100, Aoife Moloney via devel-announce wrote:
== Upgrade/compatibility impact == After upgrading to Fedora 45, Shadow Stack support will be enabled automatically for processes whose binary and all loaded shared libraries carry the appropriate markup. Processes that load any non-compliant shared object will have Shadow Stack silently disabled at startup.
Is anyone aware of any other mainstream distros that have enabled Shadow Stack yet, or is Fedora going to be the first to get the visibility of any potential lurking incompatibilities ?
== User Experience == This change is transparent to users. No action is required to enable or configure support. Applications that are not compatible with Shadow Stack run without the protection; they continue to function normally but do not benefit from the additional security. In rare cases, an application that loads a non-compliant plugin at runtime may encounter a `dlopen` error. Known affected applications ship with a drop-in configuration file that prevents this. Users who encounter this with other applications can create a file in `/etc/tunables.conf.d/` to opt the application out, and then run `ldconfig`.
"encounter a dlopen error" is rather vague.
What is the exact behaviour that users will see when an app dlopens a library that is not shadow stack compatible ? Will the application in question crash/abort, or will it report a generic or specific error message and can apps expect to gracefully degrade in some manner ?
How will users diagnose that the problem is specifically related to shadow stacks incompatiblity, in order to know to turn off the feature ?
Editting an /etc/tunables.conf.d file is not going to be so nice if users are dealing with pre-built containers from a 3rd party.
Is there any system global mechanism to turn off ShadowStacks that would be inherited by containers too ? I guess since this sounds like purely a glibc control mechanism, there's no kernel cmdline boot arg to disable this feature ?
IOW if any containers were affected, users would need to mount an override for /etc/tunables.conf.d
With regards, Daniel
On Thu, Jul 2, 2026 at 7:29 AM Daniel P. Berrangé berrange@redhat.com wrote:
On Wed, Jul 01, 2026 at 05:10:00PM +0100, Aoife Moloney via devel-announce wrote:
== Upgrade/compatibility impact == After upgrading to Fedora 45, Shadow Stack support will be enabled automatically for processes whose binary and all loaded shared libraries carry the appropriate markup. Processes that load any non-compliant shared object will have Shadow Stack silently disabled at startup.
Is anyone aware of any other mainstream distros that have enabled Shadow Stack yet, or is Fedora going to be the first to get the visibility of any potential lurking incompatibilities ?
We would be the first. At least we'll hit the problems faster than we did with turning on BTI for ARM (it took a couple of years before anyone noticed how much of Fedora was broken on ARM).
== User Experience == This change is transparent to users. No action is required to enable or configure support. Applications that are not compatible with Shadow Stack run without the protection; they continue to function normally but do not benefit from the additional security. In rare cases, an application that loads a non-compliant plugin at runtime may encounter a `dlopen` error. Known affected applications ship with a drop-in configuration file that prevents this. Users who encounter this with other applications can create a file in `/etc/tunables.conf.d/` to opt the application out, and then run `ldconfig`.
"encounter a dlopen error" is rather vague.
What is the exact behaviour that users will see when an app dlopens a library that is not shadow stack compatible ? Will the application in question crash/abort, or will it report a generic or specific error message and can apps expect to gracefully degrade in some manner ?
How will users diagnose that the problem is specifically related to shadow stacks incompatiblity, in order to know to turn off the feature ?
Editting an /etc/tunables.conf.d file is not going to be so nice if users are dealing with pre-built containers from a 3rd party.
Is there any system global mechanism to turn off ShadowStacks that would be inherited by containers too ? I guess since this sounds like purely a glibc control mechanism, there's no kernel cmdline boot arg to disable this feature ?
IOW if any containers were affected, users would need to mount an override for /etc/tunables.conf.d
I'm not sure this feature is a good idea, as-is. This is an inscrutable failure mode, significantly worse than SELinux-based failures. There's no consistent logging of the failure since it depends on the runtime environment and the application.
I suspect the feature would just get globally turned off for Fedora to be practically usable. This would probably go badly for RHEL too, since it's much more common on RHEL to use software not built with the standard hardening flags and signatures there.
-- 真実はいつも一つ！/ Always, there's only one truth!
I'm not sure this feature is a good idea, as-is. This is an inscrutable failure mode, significantly worse than SELinux-based failures. There's no consistent logging of the failure since it depends on the runtime environment and the application.
I suspect the feature would just get globally turned off for Fedora to be practically usable. This would probably go badly for RHEL too, since it's much more common on RHEL to use software not built with the standard hardening flags and signatures there.
If an application or even one of its dependencies is built without shstk support, the feature is transparently disabled when the program starts up. Of course the dlopen failure mode does exist.
After upgrading to Fedora 45, Shadow Stack support will be enabled automatically for processes whose binary and all loaded shared libraries carry the appropriate markup. Processes that load any non-compliant shared object will have Shadow Stack silently disabled at startup.
Is anyone aware of any other mainstream distros that have enabled Shadow Stack yet, or is Fedora going to be the first to get the visibility of any potential lurking incompatibilities ?
We will be the first.
This reminds me of: Freedom, Friends, Features, First.
== User Experience == This change is transparent to users. No action is required to enable or configure support. Applications that are not compatible with Shadow Stack run without the protection; they continue to function normally but do not benefit from the additional security. In rare cases, an application that loads a non-compliant plugin at runtime may encounter a `dlopen` error. Known affected applications ship with a drop-in configuration file that prevents this. Users who encounter this with other applications can create a file in `/etc/tunables.conf.d/` to opt the application out, and then run `ldconfig`.
"encounter a dlopen error" is rather vague.
What is the exact behaviour that users will see when an app dlopens a library that is not shadow stack compatible ? Will the application in question crash/abort, or will it report a generic or specific error message and can apps expect to gracefully degrade in some manner ?
How will users diagnose that the problem is specifically related to shadow stacks incompatiblity, in order to know to turn off the feature ?
This will depend on how the application handles a dlopen failure. If it assumes success, there will be a null pointer dereference and a crash when it tries to proceed. On the other hand, the application could gracefully fail or degrade when dlopen fails. We provide an error message.I did mention it in the change proposal:
"error: dlopen: /path/to/library.so: rebuild shared object with SHSTK support enabled"
This error message sounds confusing and isn't relevant to the user.
I'll file a ticket to work on improving this.
Editting an /etc/tunables.conf.d file is not going to be so nice if users are dealing with pre-built containers from a 3rd party.
Is there any system global mechanism to turn off ShadowStacks that would be inherited by containers too ? I guess since this sounds like purely a glibc control mechanism, there's no kernel cmdline boot arg to disable this feature ?
IOW if any containers were affected, users would need to mount an override for /etc/tunables.conf.d
The enablement status of shadow stack is a container property. If the hardware supports it, the container inherits the capability to use it. Even when the capability is available, whether the container runs its application in shadow stack mode depends on the container runtime, i.e. the glibc dynamic loader inside the container.
Regarding the kernel command line, I believe the capability can be turned off. i.e. the kernel will not offer it to userspace.
This change enables Shadow Stack protection on applications and libraries built with gcc (C, C++), [...]
Only C and C++? Or everything compiled with GCC and -fcf-protection?
Readelf shows "IBT, SHSTK" for several of our Ada libraries, so it would seem like those are compliant – but those properties are missing from Libgnat, which all Ada code is linked to. Thus I'm wondering whether the GCC package just needs to be fixed to build a compliant Libgnat, or whether there's some deeper reason why the protection works only for C and C++.
While Ada is much more resistant to buffer overflows than C, many Ada programs are linked to libraries written in C (because reimplementing all the libraries would be a lot of work). It would be unfortunate if those libraries would lose this protection when loaded by an Ada program.
Björn Persson
On Sunday, 5 July 2026 23:09:38 Central European Summer Time Björn Persson wrote:
Only C and C++? Or everything compiled with GCC and -fcf-protection?
The latter. Shadow stacks will be enabled for all binaries that carry the `SHSTK` note*), regardless of the programming language they were written in.
*) considering the executables themselves plus the transitive hull of all shared libs on which they depend
Best regards, Christoph
Wiki - https://fedoraproject.org/wiki/Changes/ShadowStack == Early Testing (Optional) == A COPR repository with the updated glibc (Shadow Stack enabled) is available for Fedora 43, 44, and Rawhide for early testing: https://copr.fedorainfracloud.org/coprs/submachine/glibc-x86_64-SHSTK-Testin...
This repo is not useful for testing of Rawhide now, because it's too old. Packages have been rebuilt against newer glibc and installation fails with: - installed package sqlite-libs-3.53.3-1.fc45.x86_64 requires libm.so.6(GLIBC_2.44)(64bit), but none of the providers can be installed
Zbyszek
Wiki - https://fedoraproject.org/wiki/Changes/ShadowStack == Early Testing (Optional) == A COPR repository with the updated glibc (Shadow Stack enabled) is available for Fedora 43, 44, and Rawhide for early testing: https://copr.fedorainfracloud.org/coprs/submachine/glibc-x86_64-SHSTK-Testin...
This repo is not useful for testing of Rawhide now, because it's too old. Packages have been rebuilt against newer glibc and installation fails with:
- installed package sqlite-libs-3.53.3-1.fc45.x86_64 requires libm.so.6(GLIBC_2.44)(64bit), but none of the providers can be installed
I updated it, and it should now be up-to-date for Fedora 44 and 45 now. I have dropped 43 and updated the change proposal to reflect this.
On Tue, Jul 21, 2026 at 12:49:59PM +0200, Arjun Shankar wrote:
Wiki - https://fedoraproject.org/wiki/Changes/ShadowStack == Early Testing (Optional) == A COPR repository with the updated glibc (Shadow Stack enabled) is available for Fedora 43, 44, and Rawhide for early testing: https://copr.fedorainfracloud.org/coprs/submachine/glibc-x86_64-SHSTK-Testin...
This repo is not useful for testing of Rawhide now, because it's too old. Packages have been rebuilt against newer glibc and installation fails with:
- installed package sqlite-libs-3.53.3-1.fc45.x86_64 requires libm.so.6(GLIBC_2.44)(64bit), but none of the providers can be installed
I updated it, and it should now be up-to-date for Fedora 44 and 45 now. I have dropped 43 and updated the change proposal to reflect this.
I saw that, thanks!
Second request: please enable the i686 build too. I have glibc.i686 installed for various reasons and the lack of the i686 build causes a problem with the upgrade.
(Maybe this will help others trying to test this: qemu-10.x in F44 does not have support for shadowstacks. After recompiling qemu from rawhide, upgrading, and doing 'systemctl restart libvirtd', I get user_shstk in /proc/cpuinfo on the guest.)
Zbyszek
On Tue, Jul 21, 2026 at 11:09:11AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Jul 21, 2026 at 12:49:59PM +0200, Arjun Shankar wrote:
Wiki - https://fedoraproject.org/wiki/Changes/ShadowStack == Early Testing (Optional) == A COPR repository with the updated glibc (Shadow Stack enabled) is available for Fedora 43, 44, and Rawhide for early testing: https://copr.fedorainfracloud.org/coprs/submachine/glibc-x86_64-SHSTK-Testin...
This repo is not useful for testing of Rawhide now, because it's too old. Packages have been rebuilt against newer glibc and installation fails with:
- installed package sqlite-libs-3.53.3-1.fc45.x86_64 requires libm.so.6(GLIBC_2.44)(64bit), but none of the providers can be installed
I updated it, and it should now be up-to-date for Fedora 44 and 45 now. I have dropped 43 and updated the change proposal to reflect this.
I saw that, thanks!
Second request: please enable the i686 build too. I have glibc.i686 installed for various reasons and the lack of the i686 build causes a problem with the upgrade.
(Maybe this will help others trying to test this: qemu-10.x in F44 does not have support for shadowstacks. After recompiling qemu from rawhide, upgrading, and doing 'systemctl restart libvirtd', I get user_shstk in /proc/cpuinfo on the guest.)
I'm surprised you see a difference in QEMU in this respect, as I'm not aware of changes between QEMU in 10.2.2 (F44) and 11.0.0 (F45) that would affect availability of shadow stacks in the guest VM. Do you have any ideas why it might be missing from F44.
With regards, Daniel
On Tue, Jul 21, 2026 at 12:18:19PM +0100, Daniel P. Berrangé wrote:
On Tue, Jul 21, 2026 at 11:09:11AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Jul 21, 2026 at 12:49:59PM +0200, Arjun Shankar wrote:
Wiki - https://fedoraproject.org/wiki/Changes/ShadowStack == Early Testing (Optional) == A COPR repository with the updated glibc (Shadow Stack enabled) is available for Fedora 43, 44, and Rawhide for early testing: https://copr.fedorainfracloud.org/coprs/submachine/glibc-x86_64-SHSTK-Testin...
This repo is not useful for testing of Rawhide now, because it's too old. Packages have been rebuilt against newer glibc and installation fails with:
- installed package sqlite-libs-3.53.3-1.fc45.x86_64 requires libm.so.6(GLIBC_2.44)(64bit), but none of the providers can be installed
I updated it, and it should now be up-to-date for Fedora 44 and 45 now. I have dropped 43 and updated the change proposal to reflect this.
I saw that, thanks!
Second request: please enable the i686 build too. I have glibc.i686 installed for various reasons and the lack of the i686 build causes a problem with the upgrade.
(Maybe this will help others trying to test this: qemu-10.x in F44 does not have support for shadowstacks. After recompiling qemu from rawhide, upgrading, and doing 'systemctl restart libvirtd', I get user_shstk in /proc/cpuinfo on the guest.)
I'm surprised you see a difference in QEMU in this respect, as I'm not aware of changes between QEMU in 10.2.2 (F44) and 11.0.0 (F45) that would affect availability of shadow stacks in the guest VM. Do you have any ideas why it might be missing from F44.
I followed advice from Gemini. It said:
Libvirt translates human-readable feature XML names into raw CPUID flags before sending them to QEMU. Because native KVM/QEMU hypervisor virtualization support for Intel/AMD CET (Control-flow Enforcement Technology) was fully integrated into QEMU 11.0, older versions of libvirt lack cet-ss and cet-ibt in their built-in CPU mapping definitions.
and gave a link to https://www.phoronix.com/news/QEMU-11.0-Released, which says
- QEMU 11.0 on KVM now supports Control-flow Enforcement Technology (CET) virtualization.
From my side, I noticed that my host CPU has user_shstk, but the libvirt quest doesn't. The CPU was specified as 'host-passthrough'.
Zbyszek
On Tue, Jul 21, 2026 at 11:09:11AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Jul 21, 2026 at 12:49:59PM +0200, Arjun Shankar wrote:
Wiki - https://fedoraproject.org/wiki/Changes/ShadowStack == Early Testing (Optional) == A COPR repository with the updated glibc (Shadow Stack enabled) is available for Fedora 43, 44, and Rawhide for early testing: https://copr.fedorainfracloud.org/coprs/submachine/glibc-x86_64-SHSTK-Testin...
This repo is not useful for testing of Rawhide now, because it's too old. Packages have been rebuilt against newer glibc and installation fails with:
- installed package sqlite-libs-3.53.3-1.fc45.x86_64 requires libm.so.6(GLIBC_2.44)(64bit), but none of the providers can be installed
I updated it, and it should now be up-to-date for Fedora 44 and 45 now. I have dropped 43 and updated the change proposal to reflect this.
I saw that, thanks!
Second request: please enable the i686 build too. I have glibc.i686 installed for various reasons and the lack of the i686 build causes a problem with the upgrade.
(Maybe this will help others trying to test this: qemu-10.x in F44 does not have support for shadowstacks. After recompiling qemu from rawhide, upgrading, and doing 'systemctl restart libvirtd', I get user_shstk in /proc/cpuinfo on the guest.)
With the feature enabled, machine says:
Jul 21 13:21:49 rawhide systemd[1]: Failed to initialize kmod context: Operation not supported Jul 21 13:21:49 rawhide systemd-modules-load[525]: Failed to initialize libkmod context: Operation not supported Jul 21 13:21:49 rawhide systemd[1]: systemd-modules-load.service: Failed with result 'exit-code'. Jul 21 13:21:49 rawhide systemd[1]: Failed to start systemd-modules-load.service - Load Kernel Modules.
Without modules, networking is broken, etc. :( When I reboot with 'nousershstk', the message disappears and things seems to work again, so this seems to be directly related to the shadowstack feature.
Ah, with debugging enabled: Shared library 'libkmod.so.2' no available: /lib64/libzstd.so.1: rebuild shared object with SHSTK support enabled
It seems that libzstd doesn't support this for some reason. It is deep in the stack of pretty much everything ;(
Zbyszek
On Wednesday, July 1st, 2026 at 12:11, Aoife Moloney via devel-announce devel-announce@lists.fedoraproject.org wrote:
== Summary == This change enables Shadow Stack protection on applications and libraries built with gcc (C, C++), clang (C, C++), and rustc (Rust) by default on x86_64 machines that support it on Fedora Linux 45. The dynamic linker or static startup routines will activate Shadow Stack for any process whose binary and shared library dependencies are all built with Shadow Stack support (marked with ELF metadata), protecting processes by default whenever possible.
Shadow stack protection seems to be a relatively new hardware-bound feature:
https://www.kernel.org/doc/html/next/x86/shstk.html
, would it be possible to implement the enablement of this feature from within the kernel, instead of via ELF flags? Also, I am unsure what exactly these compatibility concerns are, in particular in regards to NVIDIA/OpenSSL. Are there compatibility problems within the ABI layer itself, or are the compatibility issues merely a matter of enabling a set of flags that are interpreted via an ELF loader?
- C. S. Sushi
Sent with Proton Mail secure email.
I have made a C program that should enable this feature within a program, before using `execve(2)` to execute a new program, which according to the kernel docs I've outlined in a previous email, may inherit shadow stack enablement (it definitely will, if `clone(2)` is used. If you actually want this to be enabled system wide, you should have it enabled via `systemd`, rather than via enforcement of ELF flags.
FYI, I don't know if this program actually works, since my hardware doesn't support CET features (this might actually be a serious concern for people with older hardware pre 2020):
``` #include <errno.h> #include <stdio.h> #include <string.h> #include <unistd.h>
#include <asm/prctl.h> #include <sys/syscall.h>
char *argve[] = {"tprogram.elf", NULL};
int main(void) { unsigned long feature;
feature = ARCH_SHSTK_SHSTK;
if (syscall(SYS_arch_prctl, ARCH_SHSTK_UNLOCK, feature) < 0) { fprintf(stderr, "Error (failed to unlock): %s.\n", strerror(errno)); return 1; }
if (syscall(SYS_arch_prctl, ARCH_SHSTK_ENABLE, feature) < 0) { fprintf(stderr, "Error (failed to enable): %s.\n", strerror(errno)); return 1; }
execve("./tprogram.elf", argve, NULL);
return 0; } ```
- C. S. Sushi
Sent with Proton Mail secure email.
On Tuesday, July 14th, 2026 at 17:44, CS Sushi Man via devel devel@lists.fedoraproject.org wrote:
On Tuesday, July 14th, 2026 at 18:24, CS Sushi Man via devel devel@lists.fedoraproject.org wrote:
if (syscall(SYS_arch_prctl, ARCH_SHSTK_UNLOCK, feature) < 0) { fprintf(stderr, "Error (failed to unlock): %s.\n", strerror(errno)); return 1; }
If the code I sent doesn't work, try removing the if-block I quoted above. Linux might not like the prospect of non-root programs unlocking/locking this feature.
- C. S. Sushi
Sent with Proton Mail secure email.
Sorry, I forgot to this part of the docs:
Exec
On exec, shadow stack features are disabled by the kernel. At which point, userspace can choose to re-enable, or lock them.
---
This kernel documentation is very confusing. I guess *this* is the reason why programs must be compiled with this feature enabled? I don't know why this feature can't be enabled via the kernel to be inherited on exec, so that all programs can just have it on by default, if you really want to.
This is kind of annoying, and I don't understand why exactly it is done this way, since it basically breaks compatibility with NVIDIA, and other proprietary software that you can't directly compile. Scratch my `systemd` suggestion, it isn't possible with the current kernel. Programs will have to have this kernel feature enabled by the program that's being executed *itself,* which is an extremely odd implementation detail that makes no sense IMHO.
The implementation of this feature overall seems to be a complete mess, on both the kernel/GCC+LLVM side. I don't really understand the point of the ELF loader flag, when userspace program loaders can't even exec programs to have the feature enabled before a given program's execution execution even begins. What were they thinking??!?
Is there some ABI thing that I'm missing here that would break ordinary programs, if the feature was forced on without any specific compiler flags?
-- Conclusion --
I don't believe this should be enabled by default, since it might break compatibility with any hardware over 5 years old. I don't think enabling this by default on a separate "security-focused" ISO would be a bad idea, however. In fact, I believe many users would like the addition of security-focused ISOs to Fedora Workstation, and Fedora Server, with a small set of changes that makes Fedora far more secure, and might break compatibility for some users, who prefer older hardware, or prefer to use their machines in a less-secure manner.
Sent with Proton Mail secure email.
On Tuesday, July 14th, 2026 at 18:40, CS Sushi Man via devel devel@lists.fedoraproject.org wrote:
On Tuesday, July 14th, 2026 at 18:24, CS Sushi Man via devel devel@lists.fedoraproject.org wrote:
if (syscall(SYS_arch_prctl, ARCH_SHSTK_UNLOCK, feature) < 0) { fprintf(stderr, "Error (failed to unlock): %s.\n", strerror(errno)); return 1; }
If the code I sent doesn't work, try removing the if-block I quoted above. Linux might not like the prospect of non-root programs unlocking/locking this feature.
- C. S. SushiSent with Proton Mail secure email.
On Tue, Jul 14, 2026 at 11:15:34PM +0000, CS Sushi Man via devel wrote:
Sorry, I forgot to this part of the docs:
Exec
On exec, shadow stack features are disabled by the kernel. At which point, userspace can choose to re-enable, or lock them.
This kernel documentation is very confusing. I guess *this* is the reason why programs must be compiled with this feature enabled? I don't know why this feature can't be enabled via the kernel to be inherited on exec, so that all programs can just have it on by default, if you really want to.
It's the other way round; the kernel chooses the safe default, and userspace only enables protection for programs that will actually work with it. See below.
This is kind of annoying, and I don't understand why exactly it is done this way, since it basically breaks compatibility with NVIDIA, and other proprietary software that you can't directly compile.
It's the other way round: enabling this feature for all programs would break third-party programs that do not support it.
I guess you missed a very important, essential part of the shadow stack design: not all userspace programs will work with it.
I don't know if you were around the Linux/*BSD ecosystems around the time when people started trying to introduce non-executable stack as a security measure, but it became clear very quickly that there are programs out there, programs used by many people, that do funny things with their stack: they place code there, they do a longjmp() and skip a couple of POPs, they deliberately pop a frame just because they want to do something even weirder... Those programs exist. Some of them have changed the way they work (e.g. because people really wanted a non-executable stack), but some of them are still unchanged, and others still do weird things that may be compatible with a non-executable stack, but will fail with a shadow stack.
This is why the executable files need to be specially marked as "this specific program can run with CET enabled, it doesn't do anything funny".
This is why the kernel cannot blindly enable this kind of protection and then execute an ELF loader only for the ELF loader to suddenly find that the program does not support it; the whole point of the security measure is that once it has been enabled, it cannot be disabled by userspace code, so the ELF loader cannot execute a program that won't work with it.
And this is where the mention of NVIDIA, ROCm, etc, comes in: these are simply the most commonly used examples of third-party vendor binary blobs, programs that neither the OS distributor nor the user has any control over, programs that may or may not work with shadow stack enabled. This is exactly why it is very important for this flag to be part of the program executable file. So if the kernel unconditionally enabled it, and then AMD shipped a ROCm binary that did something funny with its stack, the user would be very unhappy.
Scratch my `systemd` suggestion, it isn't possible with the current kernel. Programs will have to have this kernel feature enabled by the program that's being executed *itself,* which is an extremely odd implementation detail that makes no sense IMHO.
The implementation of this feature overall seems to be a complete mess, on both the kernel/GCC+LLVM side. I don't really understand the point of the ELF loader flag, when userspace program loaders can't even exec programs to have the feature enabled before a given program's execution execution even begins. What were they thinking??!?
When you start thinking like this, it is a good idea to assume good faith and reexamine your assumptions. Take a couple of steps back: is it possible you have missed some detail that makes it necessary for things to be more complicated than it seems necessary?
In this case, yes, you missed the part where there are programs that simply won't work with a shadow stack.
Is there some ABI thing that I'm missing here that would break ordinary programs, if the feature was forced on without any specific compiler flags?
Not an ABI thing, the program itself can play havoc with its stack.
-- Conclusion --
I don't believe this should be enabled by default, since it might break compatibility with any hardware over 5 years old.
I don't understand how you come to this conclusion. The whole point of this feature is to only enable it when all the preconditions are met: the hardware supports it and the executed program will not break.
G'luck, Peter
* CS Sushi Man via devel:
On Wednesday, July 1st, 2026 at 12:11, Aoife Moloney via devel-announce devel-announce@lists.fedoraproject.org wrote:
== Summary == This change enables Shadow Stack protection on applications and libraries built with gcc (C, C++), clang (C, C++), and rustc (Rust) by default on x86_64 machines that support it on Fedora Linux 45. The dynamic linker or static startup routines will activate Shadow Stack for any process whose binary and shared library dependencies are all built with Shadow Stack support (marked with ELF metadata), protecting processes by default whenever possible.
Shadow stack protection seems to be a relatively new hardware-bound feature:
On the silicon side, it is not that recent. It dates back to Ice Lake, Tiger Lake, and Zen 3. Linux support arrived very late.
Support for shadow stack to the libgcc unwinder was added in GCC 8. That must have landed in Fedora 28.
Thanks, Florian
My final opinion:
I think everything will be fine if its enabled. I accidentally skimmed over the portion where it says that the feature will be disabled if prerequisites are not met (oops), so just ignore everything I've said about *not* enabling it by default.
Sent with Proton Mail secure email.
On Wednesday, July 1st, 2026 at 12:11, Aoife Moloney via devel-announce devel-announce@lists.fedoraproject.org wrote:
== Summary == This change enables Shadow Stack protection on applications and libraries built with gcc (C, C++), clang (C, C++), and rustc (Rust) by default on x86_64 machines that support it on Fedora Linux 45. The dynamic linker or static startup routines will activate Shadow Stack for any process whose binary and shared library dependencies are all built with Shadow Stack support (marked with ELF metadata), protecting processes by default whenever possible.
This was discussed last week at a FESCo meeting and there were four points upon which clarification was requested:
1. Rust
* Last week, rustc in Rawhide was updated to build SHSTK enabled binaries by default: https://bodhi.fedoraproject.org/updates/FEDORA-2026-8b11dfbab1
* I did an analysis of the state of Rawhide. The essential set of packages that need to be rebuilt are those which ship ".so" files built with rustc. This is so that when they are dlopen'ed by another application that is already running in SHSTK mode, there is no runtime error. The number of packages that need to be rebuilt is 85.
2. pypi wheels and other Python extensions:
I think the way to tackle this is to discuss an upstream change in cpython CFLAGS (which are, e.g. inherited by manylinux which is used to build wheels). I have a patch ready, and have started this discussion: https://discuss.python.org/t/add-x86-64-shadow-stack-support-for-linux/10830... and filed a (for now closed, but I'd say there is no definitive verdict until the discussion proceeds) issue: https://github.com/python/cpython/issues/154820
3. Nvidia drivers
I wasn't able to get the right combination of new enough CPU and Nvidia GPU to test this. But I am working on it and might get some help. e.g. I have contacted Adam and he might be able to get me something.
4. openssl modules
So far, I haven't found anything incompatible. Can someone point me to anything that is incompatible and *not* built with Rust (which can be fixed now that Rust is updated):
/usr/lib64/ossl-modules/fips.so Properties: x86 feature: IBT, SHSTK /usr/lib64/ossl-modules/legacy.so Properties: x86 feature: IBT, SHSTK /usr/lib64/ossl-modules/pkcs11.so Properties: x86 feature: IBT, SHSTK /usr/lib64/ossl-modules/pkcs11sign.so Properties: x86 feature: IBT, SHSTK /usr/lib64/ossl-modules/tpm2.so
- pypi wheels and other Python extensions:
I forgot to mention: we plan to change the SHSTK mode to "permissive" in glibc. This is an existing feature where, if a process is still single-threaded and in SHSTK mode, dlopen-ing a non-SHSTK object will transition back to non-SHSTK mode seamlessly. This should also help with compatibility.
Hi Arjun,
On Tuesday, 28 July 2026 18:59:55 Central European Summer Time Arjun Shankar via devel wrote:
- pypi wheels and other Python extensions:
I think the way to tackle this is to discuss an upstream change in cpython CFLAGS (which are, e.g. inherited by manylinux which is used to build wheels). I have a patch ready, and have started this discussion: https://discuss.python.org/t/add-x86-64-shadow-stack-support-for-linux/1083 09 and filed a (for now closed, but I'd say there is no definitive verdict until the discussion proceeds) issue: https://github.com/python/cpython/issues/154820
in my understanding, the correct place for this is the PyPA's manylinux project. I have opened a draft pull request with them: https://github.com/pypa/manylinux/pull/1970
... and was asked to launch a discussion thread in the Python Packaging forum: https://discuss.python.org/t/building-extensions-with-hardening-flags-via-ma...
Best regards, Christoph
On Fri, Jul 31, 2026 at 6:47 PM Christoph Erhardt fedora@sicherha.de wrote:
in my understanding, the correct place for this is the PyPA's manylinux project. I have opened a draft pull request with them: https://github.com/pypa/manylinux/pull/1970
... and was asked to launch a discussion thread in the Python Packaging forum: https://discuss.python.org/t/building-extensions-with-hardening-flags-via-ma...
Thanks! I also see that this has kicked off an actual discussion whereas my (possibly incorrectly labeled) discussion didn't. Thanks for working on this. I'm going to respond there when I get back to work this coming week.
I'm going to put this on the record for when Fedora decides to go further towards enabling the shadow stack from `permissive`, to `on`. The link below points to a suggestion made by a Python forum user, detailing a suggestion for Fedora packagers.
https://discuss.python.org/t/building-extensions-with-hardening-flags-via-ma...
Of course, an action plan is at your discretion. :-)
Sent with Proton Mail secure email.
I'm going to put this on the record for when Fedora decides to go further towards enabling the shadow stack from `permissive`, to `on`. The link below points to a suggestion made by a Python forum user, detailing a suggestion for Fedora packagers.
https://discuss.python.org/t/building-extensions-with-hardening-flags-via-ma...
Of course, an action plan is at your discretion. :-)
Thanks! Most packages should already be built with SHSTK compatibility, but testing the runtime is an undertaking. I'll file a separate task for testing some major python applications.
Thanks!
Sent with Proton Mail secure email.
On Sunday, August 2nd, 2026 at 18:32, Arjun Shankar via devel devel@lists.fedoraproject.org wrote:
I'm going to put this on the record for when Fedora decides to go further towards enabling the shadow stack from `permissive`, to `on`. The link below points to a suggestion made by a Python forum user, detailing a suggestion for Fedora packagers.
https://discuss.python.org/t/building-extensions-with-hardening-flags-via-ma...
Of course, an action plan is at your discretion. :-)
Thanks! Most packages should already be built with SHSTK compatibility, but testing the runtime is an undertaking. I'll file a separate task for testing some major python applications.
-- Arjun Shankar he/him/his
--
-
Aoife Moloney via devel-announce -
Arjun Shankar -
Björn Persson -
Christoph Erhardt -
CS Sushi Man -
Daniel P. Berrangé -
Dmitry Belyavskiy -
Florian Weimer -
Gary Buhrmaster -
Neal Gompa -
Peter Pentchev -
Richard W.M. Jones -
Vitaly Zaitsev -
Zbigniew Jędrzejewski-Szmek