The grsecurity "RAP" patch set

determining the xor cookie isn't enough to return to an arbitrary address since the target still must be marked with the proper return type hash, i.e., it must be a valid (intended) return location for the given type. note also that the primary use case for the xor cookie method is the kernel where we have much better control over cookie leaks (and where PKU doesn't exist, unfortunately). that said, i don't see how PKU would help with infoleaks as a thread can leak its own cookie (or derived data) into shared (=visible to other threads) regions as well or just send it through a file descriptor as data. as for unreadable code, that can help at most when the attacker doesn't have access to the code offline already (think distro binaries, etc) which i think is a rare case in real life, not to mention that it's also incompatible with RAP's type hash based checks as the hashes are embedded in the code for performance.