On Thu, Jul 2, 2026 at 7:29 AM Daniel P. Berrangé <[email protected]> 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! -- _______________________________________________ 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
