... and then you're still stuck with a browser & a JIT engine, and all your CFI goes out of the window if an attacker gets arbitrary r/w first.

I mean, reality is: Most pwnage happens through the browser now, and CFI is simply not effective in the presence of all mainstream JITs.

When using out-of-process JIT (As in Edge), the JIT code is RO in JIT process. Thus, CFI hashes compared on fwd-edges and the compare itself are in RO mem. i.e. XFG/RAP fwd-edges still work. Same is true for RAP backward-edges (ret hashes and compares are in RO memory as-well).

I was not talking about writing to +x pages. If any +X address space is ever reused -> break.

Right. So can you elaborate why would attacker's arbitrary read/write break RAP's CFI? Shadow-stack should also always remain read-only. In RFG it was only hidden but still writable which lead it indeed to be not effective, but this isn't true for CET-like shadow-stack.

Arbitrary RW means I can have a callchain that goes from C++FuncA -> JITedCodeB -> C++FuncC, and I can then make the JIT engine garbage-collect JITedCodeB and put different code there. Not violating any CFI constraints, but executing arbitrary code.

That basically means you already have a poor CFI constrain at the start, whereby what you call from C++FuncA doesn’t validate its target (basically all JIT is equally trusted). And of course, CFI won’t do anything against data oriented attacks, which can equally influence exec :)

I think you misunderstand: The call from C++FuncA can do all the validating it wants, it's the return from C++FuncC that returns into different code than it left.

and how will you make sure that the replacement has a matching return type hash (and the rest of it is useful enough to do your bidding)?

I think at this point we're talking about RAP, not CET?