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

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-stack-by-default-on-x86-64-system-wide/195400
> 
> 
> 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/[email protected]/T/#u
> 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
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

-- 
_______________________________________________
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