On Mon, 2022-11-07 at 13:21 -0800, H.J. Lu wrote: > > > Some applications and libraries are compiled with -fcf- > > > protection, > > > but > > > they manipulate the stack in such a way that they aren't > > > compatible > > > with the shadow stack. However, if the build/test setup doesn't > > > support > > > shadow stack, it is impossible to validate. > > > > > > > When we have everything in place, the problems would be much more > > obvious when distros started turning it on. But we can't turn it on > > as > > Not necessarily. The problem will show up only in a CET enabled > environment since build/test setup may not be on a CET capable > hardware. Well, I'm not sure of the details of distro testing, but there are plenty of TGL and later systems out there today. With kernel support, I'm thinking these types of problems couldn't lurk for years like they have. > > > planned without breaking things for existing binaries. We can have > > both > > by: > > 1. Choosing a new bit, adding it to the tools, and never supporting > > the > > old bit in glibc. > > 2. Providing the option to have the kernel block the old bit, so > > upgraded users can decide what experience they would like. Then > > distros > > can find the problems and adjust their packages. I'm starting to > > think > > a default off sysctl toggle might be better than a Kconfig. > > 3. Any other ideas? > > Don't enable CET in glibc until we can validate CET functionality. Can you elaborate on what you mean by this? Not upstream glibc CET support? Or have users not enable it? If the latter, how would they know about all these problems. And what is wrong with the cleanest option, number 1? The ABI document can be updated.
