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. -- H.J.
