Change: Enable Shadow Stack by Default on x86_64 #3636
Labels
No labels
document it
fast track
meeting
next release
nonresponsive maintainer
packager revocation
pending announcement
provenpackager
python 2 exception
self contained change
stalled
Status
Accepted
Status
Duplicate
Status
Insufficient data
Status
Invalid
Status
Rejected
system wide change
updates policy exception
vote-in-progress
No milestone
No project
No assignees
7 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
fesco/tickets#3636
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.
Owners, do not implement this work until the FESCo vote has explicitly ended.
When a FESCo member has marked this ticket as APPROVED, you may proceed with the implementation. See the FESCo ticket policy and the Changes policy for more information.
If no decision has been rendered after 7 days from the filing of this ticket and no indication (such as a -1 vote) that this will be taken up at a FESCo meeting, please feel free to ping for a status update.
REMINDER: This ticket is for FESCo members to vote on the proposal. Further discussion should happen in the Discourse discussion linked above. Additional discussion may happen on the Fedora Devel mailing list.
@amoloney wrote in #3636 (comment):
This shoud link to the devel post, not the devel-announce post. There were discussions that occurred on the devel list that should be considered here.
-1. Based on the discussions on the list and on Discourse, it seems this could have a very large impact, including on third-party openssl providers, Python wheels from PyPI, NVIDIA drivers, and potentially others. Even if some of this affected software isn't shipped directly in Fedora, we don't want to knowingly break things. Is there a plan to mitigate these issues? If so, the Change should be updated.
@gotmax23 I didnt realise there was a formal change from the devel-announce link to the devel one as the devel-announce link is in the pagure template which is linked from the PgM SOP https://docs.fedoraproject.org/en-US/operations/pgm_guide/sop/changes-submit/
Also it is not as easy to find change email links from hyperkitty from the devel list. I suspect only changes that are announced and have some replies show up on the devel-list. It is much easier (and quicker for me) to pull links from the devel-announce, as has been the process.
It's basically the same link, since the message IDs are the same when lists.fedoraproject.org automatically forwards posts from devel-announce@ to devel@. You can take the
devel-announcelink and changedevel-announcetodevel, and then the link should point to the full discussion on the devel list.I think this change is very welcome, iff we can mitigate the breakage for people. I think it's too early to vote, before we have clarity on the details of the plan. There's a number of things still under discussion:
In particular, I think we need opt-out through environment variables for this to be viable. Take
/usr/bin/pythonfor example: it may work totally fine in the new scheme for most things, but then one wants to use some module from pypi, and the existing opt-out based on executable name is not enough. We need a flexible per-user and per-usecase settings for this.But if those issues are mitigated, I'd be ready to vote +1.
Indeed, that was why I asked, "Is there a plan to mitigate these issues? If so, the Change should be updated."
This, at least, is an example of a very common usecase that should Just Work. End users should be able to
pip installcommon packages in a virtual environment without needing to set additional environment variables or configuration settings.As things currently stand, I'm -1. I don't think there's a reasonable mitigation strategy that would keep people from saying "Fedora is broken" by default.
There is at least one
-1vote here, so I am marking this withmeetingas per procedure. It will likely be discussed in the 2026-07-21 FESCo meeting at 18:00 Europe/London (currently 17:00 UTC) in https://matrix.to/#/#meeting:fedoraproject.org.. @submachine, you are invited to attend if you'd like.As far as I can tell, both the impact on things that will stop working without workarounds and the amount of programs in Fedora that won't benefit by default is being underestimated here - mostly due to lack of support for shadow stack in Rust.
That means both that Python packages with native extensions built in Rust won't have shadow stack support and programs that load them will need to opt out (?), and that anything that links to C-ABI libraries implemented in Rust (librpm-sequoia, librsvg2, librav1e, etc.) will be opted out automatically. So this probably includes most of GNOME, the entire package management stack, and anything that links ffmpeg.
To summarize, I don't think this Change is workable as-is. -1
It also affects the KDE stack too, since Rust is used in parts of it too (the Union style engine, KDE PIM, etc.).
@decathorpe wrote in #3636 (comment):
Rust support has already been discussed with the Rust team and mentioned as a dependency in the change request. We have already tested a change to the Rust compiler that enables Shadow Stack support. We were provided with a rustc COPR that contains the test rustc package (https://copr.fedorainfracloud.org/coprs/jistone/rust-shstk/) and we rebuilt rust packages in Fedora to test it (https://copr.fedorainfracloud.org/coprs/submachine/rust-shstk-rebuilds-v2-full/builds/). Only ~30 out of over 3500 packages failed to build and all were investigated and found to be unrelated to the Shadow Stack enablement.
We already have agreement from the Rust team that once this change proposal is approved, they will update rustc to enable Shadow Stack support.
@zbyszek wrote in #3636 (comment):
Rawhide already has support for configurable opt-out because system-wide tunables support was merged upstream, and glibc in Rawhide tracks upstream. While there has been discussion on fedora-devel on the Shadow Stack proposal thread about what the ideal location of the file should be, Fedora 45 will already ship with support for system-wide tunable configuration at /etc/tunables.conf, because that's the direction upstream glibc has already taken. We can of course discuss a change to the location and take that discussion upstream. But a clear configurable opt-out mechanism is already present.
This has been available for a while now via GLIBC_TUNABLES.
GLIBC_TUNABLES="glibc.cpu.x86_shstk=off" as well as GLIBC_TUNABLES="glibc.cpu.hwcaps=-SHSTK" disable shadow stack support.
Are you referring to error messages?
The environment variables do provide this. On top of that, config file support can now allow an administrator to restrict users from being able to opt-out for specific binaries.
This will be discussed in the meeting today at 18:00 Europe/London.
This was discussed during the meeting today:
ACTION: Arjun Shankar will on providing more information for the points raised in discussion.
INFO: We'll revisit the topic next week.
INFO: A clarified plan for Rust, pypi wheels and other Python extensions, nvidia drivers, and openssl modules is requested.
This was APPROVED (+8, 0, -0) in today's meeting, but retargeted for F46 (cc: @amoloney to retarget)
Announced in https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GGQQSJ2NVYJIH4TJKOOPEBZ4TX4VQCLI/