On Mon, 2022-11-07 at 11:10 -0800, H.J. Lu wrote: > On Mon, Nov 7, 2022 at 9:47 AM Edgecombe, Rick P > <rick.p.edgecombe@xxxxxxxxx> wrote: > > > > On Mon, 2022-11-07 at 17:55 +0100, Florian Weimer wrote: > > > * Rick P. Edgecombe: > > > > > > > On Sun, 2022-11-06 at 10:33 +0100, Florian Weimer wrote: > > > > > * H. J. Lu: > > > > > > > > > > > This change doesn't make a binary CET compatible. It just > > > > > > requires > > > > > > that the toolchain must be updated and all binaries have to > > > > > > be > > > > > > recompiled with the new toolchain to enable CET. It > > > > > > doesn't > > > > > > solve > > > > > > any > > > > > > issue which can't be solved by not updating glibc. > > > > > > > > > > Right, and it doesn't even address the library case (the > > > > > kernel > > > > > would > > > > > have to hook into mmap for that). The kernel shouldn't do > > > > > this. > > > > > > > > Shadow stack shouldn't enable as a result of loading a library, > > > > if > > > > that's what you mean. > > > > > > It's the opposite—loading incompatible libraries needs to disable > > > shadow > > > stack (or ideally, not enable it in the first place). > > > > The glibc changes I have been using would not have enabled shadow > > stack > > in the first place unless the execing binary has the elf bit. So > > the > > binary would run as if shadow stack was not enabled in the kernel > > and > > there should be nothing to disable when an incompatible binary is > > loaded. Glibc will have to detect this and act accordingly because > > not > > all kernels will have shadow stack configured. > > > > > Technically, I > > > think most incompatible code resides in libraries, so this kernel > > > change > > > achieves nothing besides punishing early implementations of the > > > published-as-finalized x86-64 ABI. > > > > It's under the assumption that not breaking things is more > > important > > than having shadow stack enabled. So it is not intended as a > > punishment > > for users at all, rather the opposite. > > > > I'm not sure how much the spec mandates things by the letter of it, > > but > > in any case things have gone wrong in the real world. I am very > > open to > > discussion here. I only went this way as a last resort because I > > didn't > > hear back on the last thread. > > 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 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?
