On Wed, Jul 1, 2026 at 6:11 PM Aoife Moloney via devel-announce < [email protected]> wrote:
> Wiki - https://fedoraproject.org/wiki/Changes/ShadowStack > Discussion thread - > > https://discussion.fedoraproject.org/t/f45-change-proposal-enable-shadow-stack-by-default-on-x86-64-system-wide/195400 > > > == 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/[email protected]/T/#u > System-Wide > <https://inbox.sourceware.org/libc-alpha/[email protected]/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). -- Dmitry Belyavskiy
-- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
