So this limits the number of gadget options you have for ROP, but doesn't eliminate ROP entirely, right? It maybe increases the difficulty of ROP, if you can't find enough/sufficient gadgets that happen to start after function call sites. Not a silver bullet, anyway.
Well, it means that modulo hash collisions, a function can only return to one of the places which calls that function, so in the really tragic case (for example) that someone called a vulnerable function and then immediately after called system() with a stack variable as the arg, the attacker can just return there and make the arg point to "bash". But in general the whole business of knitting together assembly instructions in executable memory would pretty much be gone.
Edit: typo, clarity
Is it really limited to only call sites of that function, or to all call sites? I can't tell if their return cookie is shared throughout the binary or unique to callees.
One approach is to assign a random 2 byte number to each function and all callers to that function must follow the call with those 2 bytes (with a jmp 2 so it doesn't try to execute them). Unfortunately this would require the linker to get involved because we're not going to know these cookies at compile time.
Another approach is to take a hash of the types of the args and the return value (pointers obviously being opaque). This way we know the cookie value for any given function at compile time and we can stay out of the linker. However, in this case function a(int, char) can return to the call sight of function b(int, char) because to the code they're identical.
The problem with per-function cookies are dynamic calls. The only feasible options I can think of is are either a) a secondary cookie that is allowed from all functions or b) a shadow stack with the cookies.
