I am baffled by this discussion.

quoted

On Mar 9, 2020, at 5:09 PM, H.J. Lu [off-list ref] wrote:

On Mon, Mar 9, 2020 at 4:59 PM Andy Lutomirski [off-list ref] wrote:

quoted

quoted

quoted

.

This could presumably have been fixed by having libpcre or sljit
disable IBT before calling into JIT code or by running the JIT code in
another thread.  In the other direction, a non-CET libpcre build could
build IBT-capable JITted code and enable JIT (by syscall if we allow
that or by creating a thread?) when calling it.  And IBT has this

This is not how thread in user space works.

void create_cet_thread(void (*func)(), unsigned int cet_flags);

I could implement this using clone() if the kernel provides the requisite support. Sure, creating threads behind libc’s back like this is perilous, but it can be done.

quoted

fancy legacy bitmap to allow non-instrumented code to run with IBT on,
although SHSTK doesn't have hardware support for a similar feature.

All these changes are called CET enabing.

What does that mean?  If program A loads library B, and library B very carefully loads CET-mismatched code, program A may be blissfully unaware.

quoted

So, sure, the glibc-linked ELF ecosystem needs some degree of CET
coordination, but it is absolutely not the case that a process MUST
have all CET or no CET.  Let's please support the complicated cases in
the kernel and the ABI too.  If glibc wants to make it annoying to do
complicated things, so be it.  People work behind glibc's back all the
time.

CET is no different from NX in this regard.

NX is in the page tables, and CET, mostly, is not.  Also, we seriously flubbed READ_IMPLIES_EXEC and made it affect far more mappings than ever should have been affected.

If a legacy program (non-NX-aware) loads a newer library, and the library opens a device node and mmaps it PROT_READ, it gets RX.  This is not a good design. In fact, it’s actively problematic.

Let us please not take Linux’s NX legacy support as an example of good design.