* Rick P. Edgecombe: >> I think the goal is to support the new kernel interface for actually >> switching on SHSTK in glibc 2.37. But at that point, hopefully all >> those existing binaries can start enjoying the STSTK benefits. > > Can you share more about this plan? HJ was previously planning to wait > until the kernel support was upstream before making any more glibc > changes. Hopefully this will be in time for that, but I'd really rather > not repeat what happened last time where we had to design the kernel > interface around not breaking old glibc's with mismatched CET > enablement. You're still doing that (keeping that gap in this constant), and this appreciated and very much necessary. > What did you think of the proposal to disable existing binaries and > start from scratch? Elaborated in the coverletter in the section > "Compatibility of Existing Binaries/Enabling Interface". 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.) Thanks, Florian
