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.

In short: CFI is bunk in an environment with a JIT that ever reuses +x address space.

Oh cool. You are right. I haven't thought about that attack. Thanks! :)

51%+ of credit for this needs to go to @ifsecure

Ah no, the return-after-free (as I like to call it) idea was entirely your own. My sole contribution was to drag you into a meeting.

I remember this being very much developed in ping-pong, so I will continue to attribute 51% to you :)

@grsecurity ROP attacks return flow. So saying that there is no effective mitigation against ROP might not be entirely wrong by Intel. CET shadow stack does address ROP in fine grained manner and deterministically. And assume arbitrary read/write primitive in attacker hands. /1

@grsecurity In your analysis you mentioned that attacker can use RELRO pages and perform writes to manufacture RO but dirty (thus shadow stack) pages. CET prevents that by faulting ; CR0.WP can't be cleared if CR4.CET = 1. Setting CR4.CET while CR0.WP=0 will fault. /2

And not saying above prevention is not coming at cost (like hotpatching, link pasted). It'll break things but eventually it'll improve. lists.xenproject.org/archive…

In your analysis against CET you assume arbitrary Read writes. But for RAP you propose prevention against read primitives rather than assuming read primitives are available (like CET does). Why so? /4