Re: F45 Change Proposal: Enable Shadow Stack by Default on x86_64 (system-wide)

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