"Control-Flow Integrity for the Linux kernel: A Security Evaluation" is the work I've done for my Masters thesis where I analyze how the PaX Team's (public) RAP holds up to stop ROP when applied to the Linux kernel. You may want to check out chapter 3. alunos.dcc.fc.up.pt/~up20140…

this is a sad joke for a 'thesis' i'm afraid. you should have kept true to your word and kept us in the loop about your findings to avoid all these errors.

You should also keep true to your word and assume defeat as I've found ways to bypass RAP on the public test patch?

section 3.3 is even worse. it shows an 'exploit' by changing memory directly from gdb. it only shows you couldn't even find a real bug or create one yourself to do it for real. second, you missed the fact that the xor cookie defense applies to all return addresses, iret included.

So what does assuming arbitrary r/w mean? gdb does just that, and it's easier for people to understand (not that you have experience with that). If you say so... I can't really verify that.

it's described in my H2HC15 presentation that you even linked to (reference ) but clearly never read or understood.

I understood it perfectly.

you did not otherwise you wouldn't equate debugger access to arbitrary read/write access.

So you're telling me with debugger access one can't read from and write to anywhere in memory an arbitrary number of times?