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?

you tell me, you made the sweeping comment about CFI being useless in the presence of JIT :). as for RAP and, say, chromium, it's existed since 2014 or something, with some, but certainly not complete support for its JIT engines :).

I made a sweeping statement about CFI being useless in the presence of *mainstream* JITs. See me comment to Brad; I will not start a discussion here based on hypothetical JITs that y'all have hardened.

Fact is: There is no deployed in-browser JIT that implements anything like RAP, so my above statement holds :-). Do I believe that you could possibly implement it? Yes. Do I think you will? No. So I think my sweeping statement will hold true for the next couple years at least.