[sebcat]

You need to hit the first ret in the vulnerable function to enter the ROP chain, and before that ret the value at the top of stack will be (de-)mangled.

If the return address on the stack is overwritten by an attacker, it needs to be overwritten with a ROP gadget adjusted for the mangling.

[RolfRolles]

Your comments only apply to exploitation of stack buffer overflows, which have largely been rendered extinct due to compiler-based strategies like this one. Exploiting, say, a use-after-free vulnerability still may require ROP but does not require corruption of a return address on the stack. Given that the proposed defense supposedly targets ROP in general and not exploitation of stack buffer overflows specifically, my points still stand.

[Mordak]

Oh, yes. There are other ways to kick off ROP chains that do not involve stack corruption. For these attacks, Retguard will only pollute the gadget space by inserting these return-address permuting instructions before some fraction of the c3 bytes in a program (a little under 50%, depending on the program).

Actually removing c2/c3 bytes and actively reducing the gadget space is a different endeavour. There has been a bunch of academic work in this regard, with varying levels of success. Some would say it is a fool's errand to try to remove all the ROP gadgets, but that's what fools are for. Stay tuned. :-)