summaryrefslogtreecommitdiff
path: root/Documentation/powerpc
diff options
context:
space:
mode:
authorBenjamin Gray <bgray@linux.ibm.com>2023-06-19 17:36:26 +1000
committerMichael Ellerman <mpe@ellerman.id.au>2023-06-19 17:36:27 +1000
commit97228ca375c78bfd960767dcd4919c981add306f (patch)
tree62d0c55e78da7dcd3c727821f3c07751c8cc6ce7 /Documentation/powerpc
parent884ad5c52da253e5d38f947cd8d1d9412a47429c (diff)
powerpc/ptrace: Expose HASHKEYR register to ptrace
The HASHKEYR register contains a secret per-process key to enable unique hashes per process. In general it should not be exposed to userspace at all and a regular process has no need to know its key. However, checkpoint restore in userspace (CRIU) functionality requires that a process be able to set the HASHKEYR of another process, otherwise existing hashes on the stack would be invalidated by a new random key. Exposing HASHKEYR in this way also makes it appear in core dumps, which is a security concern. Multiple threads may share a key, for example just after a fork() call, where the kernel cannot know if the child is going to return back along the parent's stack. If such a thread is coerced into making a core dump, then the HASHKEYR value will be readable and able to be used against all other threads sharing that key, effectively undoing any protection offered by hashst/hashchk. Therefore we expose HASHKEYR to ptrace when CONFIG_CHECKPOINT_RESTORE is enabled, providing a choice of increased security or migratable ROP protected processes. This is similar to how ARM exposes its PAC keys. Signed-off-by: Benjamin Gray <bgray@linux.ibm.com> Reviewed-by: Russell Currey <ruscur@russell.cc> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230616034846.311705-8-bgray@linux.ibm.com
Diffstat (limited to 'Documentation/powerpc')
0 files changed, 0 insertions, 0 deletions