On Tue, Jul 14, 2026 at 11:15:34PM +0000, CS Sushi Man via devel wrote: > Sorry, I forgot to this part of the docs: > > Exec > > On exec, shadow stack features are disabled by the kernel. At which point, > userspace can choose to re-enable, or lock them. > > --- > > This kernel documentation is very confusing. I guess *this* is > the reason why programs must be compiled with this feature enabled? > I don't know why this feature can't be enabled via the kernel to be > inherited on exec, so that all programs can just have it on by > default, if you really want to.
It's the other way round; the kernel chooses the safe default, and userspace only enables protection for programs that will actually work with it. See below. > This is kind of annoying, and I don't understand why exactly it > is done this way, since it basically breaks compatibility with > NVIDIA, and other proprietary software that you can't directly > compile. It's the other way round: enabling this feature for all programs would break third-party programs that do not support it. I guess you missed a very important, essential part of the shadow stack design: not all userspace programs will work with it. I don't know if you were around the Linux/*BSD ecosystems around the time when people started trying to introduce non-executable stack as a security measure, but it became clear very quickly that there are programs out there, programs used by many people, that do funny things with their stack: they place code there, they do a longjmp() and skip a couple of POPs, they deliberately pop a frame just because they want to do something even weirder... Those programs exist. Some of them have changed the way they work (e.g. because people really wanted a non-executable stack), but some of them are still unchanged, and others still do weird things that may be compatible with a non-executable stack, but will fail with a shadow stack. This is why the executable files need to be specially marked as "this specific program can run with CET enabled, it doesn't do anything funny". This is why the kernel cannot blindly enable this kind of protection and then execute an ELF loader only for the ELF loader to suddenly find that the program does not support it; the whole point of the security measure is that once it has been enabled, it cannot be disabled by userspace code, so the ELF loader cannot execute a program that won't work with it. And this is where the mention of NVIDIA, ROCm, etc, comes in: these are simply the most commonly used examples of third-party vendor binary blobs, programs that neither the OS distributor nor the user has any control over, programs that may or may not work with shadow stack enabled. This is exactly why it is very important for this flag to be part of the program executable file. So if the kernel unconditionally enabled it, and then AMD shipped a ROCm binary that did something funny with its stack, the user would be very unhappy. > Scratch my `systemd` suggestion, it isn't possible with > the current kernel. Programs will have to have this kernel feature > enabled by the program that's being executed *itself,* which is an > extremely odd implementation detail that makes no sense IMHO. > > The implementation of this feature overall seems to be a complete > mess, on both the kernel/GCC+LLVM side. I don't really understand > the point of the ELF loader flag, when userspace program loaders > can't even exec programs to have the feature enabled before a given > program's execution execution even begins. What were they > thinking??!? When you start thinking like this, it is a good idea to assume good faith and reexamine your assumptions. Take a couple of steps back: is it possible you have missed some detail that makes it necessary for things to be more complicated than it seems necessary? In this case, yes, you missed the part where there are programs that simply won't work with a shadow stack. > Is there some ABI thing that I'm missing here that would break > ordinary programs, if the feature was forced on without any > specific compiler flags? Not an ABI thing, the program itself can play havoc with its stack. > -- Conclusion -- > > I don't believe this should be enabled by default, since it might > break compatibility with any hardware over 5 years old. I don't understand how you come to this conclusion. The whole point of this feature is to only enable it when all the preconditions are met: the hardware supports it and the executed program will not break. G'luck, Peter -- Peter Pentchev [email protected] [email protected] [email protected] PGP key: https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
-- _______________________________________________ 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
