On Thu, 2023-03-30 at 16:50 +1100, Benjamin Gray wrote: > 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 <bg...@linux.ibm.com>
Seems sensible Reviewed-by: Russell Currey <rus...@russell.cc>
