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 <redacted>
Seems sensible
Reviewed-by: Russell Currey <redacted>