mirror of
https://mirrors.bfsu.edu.cn/git/linux.git
synced 2025-01-18 03:44:27 +08:00
97228ca375
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 |
||
|---|---|---|
| .. | ||
| Makefile | ||
| ptrace32.c | ||
| ptrace-adv.c | ||
| ptrace-altivec.c | ||
| ptrace-decl.h | ||
| ptrace-fpu.c | ||
| ptrace-noadv.c | ||
| ptrace-novsx.c | ||
| ptrace-spe.c | ||
| ptrace-tm.c | ||
| ptrace-view.c | ||
| ptrace-vsx.c | ||
| ptrace.c | ||