On Wed, 2022-10-12 at 14:29 +0200, Florian Weimer wrote: > The ABI was finalized around four years ago, and we have shipped > several > Fedora and Red Hat Enterprise Linux versions with it. Other > distributions did as well. It's a bit late to make changes now, and > certainly not for such trivialities. In the case of the IBT ABI, it > may > be tempting to start over in a less trivial way, to radically reduce > the > amount of ENDBR instructions. But that doesn't concern SHSTK, and > there's no actual implementation anyway. > > But as H.J. implied, you would have to do rather nasty things in the > kernel to prevent us from achieving ABI compatibility in userspace, > like > parsing property notes on the main executable and disabling the new > arch_prctl calls if you see something there that you don't like. 8-) > Of course no one is going to implement that. > > (We are fine with swapping out glibc and its dynamic loader to enable > CET with the appropriate kernel mechanism, but we wouldn't want to > change the way all other binaries are marked up.) So we have these compatibility issues with existing binaries. We know some apps are totally broken. It sounds like you are proposing to ignore this and let people who hit the issues work through it themselves. This was also proposed by other glibc developers as a solution for past CET compatibility issues that broke boot on kernel upgrade. I have to say, as the person pushing these patches, I’m uncomfortable with this approach. I don’t think users will like the results. Basically, do they want to upgrade and run a bunch of untested integration with known failures? I also don’t want to get this feature reverted and I’m not exactly sure how this scenario would be taken. But I hear the point about it not being ideal to abandon the existing CET userspace. I think there is also a point about how userspace chose to do this optimistic and early wide enabling, even if it was a bad idea, and so how much should the kernel try to save userspace from itself. So what do you think about this instead: The current psABI spec talks about the binary being compatible with shadow stack. It doesn’t say much about what should happen after the loader. Since the greater ecosystem has used this bit with a more cavalier attitude, glibc could treat it as a request for a warn and continue mode. In the meantime we could have a new bit shstk_strict, that requests behavior like these patches implement, and kills the process on violation. Glibc/tools could add support for this strict bit and anyone that wants to more carefully compile with it could finally get shadow stack today. Then the implementation of the warn and continue mode could follow that, and glibc could map the original shstk bit to that kernel mode. So the old binaries would get there eventually, which is better than the continuing nothing they have today. And speaking of having nothing today, there are people that really want to use shadow stack and do not care at all about having CET support for existing binaries. Neither glibc or elf bits are required to use kernel shadow stack support. So if it comes to it, I don’t want to hold support back for other users because the elf note bit enabling path grew some issues. Please let me know about what you think of that plan.
