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.
