Re: [PATCH 4/9] powerpc/dexcr: Support userspace ROP protection

[Michael Ellerman <mpe@ellerman.id.au>]

Benjamin Gray <bgray@linux.ibm.com> writes:
> The ISA 3.1B hashst and hashchk instructions use a per-cpu SPR HASHKEYR
> to hold a key used in the hash calculation. This key should be different
> for each process to make it harder for a malicious process to recreate
> valid hash values for a victim process.
>
> Add support for storing a per-thread hash key, and setting/clearing
> HASHKEYR appropriately.
>
> Signed-off-by: Benjamin Gray <bgray@linux.ibm.com>
>
> ---
>
> v1:	* Guard HASHKEYR update behind change check
> 	* HASHKEYR reset moved earlier to patch 2
> ---
>  arch/powerpc/include/asm/processor.h |  1 +
>  arch/powerpc/kernel/process.c        | 17 +++++++++++++++++
>  2 files changed, 18 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/processor.h b/arch/powerpc/include/asm/processor.h
> index bad64d6a5d36..666d4e9804a8 100644
> --- a/arch/powerpc/include/asm/processor.h
> +++ b/arch/powerpc/include/asm/processor.h
> @@ -264,6 +264,7 @@ struct thread_struct {
>  	unsigned long   mmcr3;
>  	unsigned long   sier2;
>  	unsigned long   sier3;
> +	unsigned long	hashkeyr;
  
hashkeyr is part of the thread state, so we should save it in core dumps.

The DEXCR also influences the threads behaviour, at least by
enabling/disabling hashst/chk, so I think we should also include it in
core dumps.

Adding regs to the core dump is done by adding eg. a new NT_PPC_HASHKEY
entry in include/uapi/linux/elf.h and wiring it up in ptrace.

But those are a non-renewable resource, so if we're going to add
HASHKEYR and DEXCR it would be better to group them as a single note. I
think given that HASHKEYR doesn't exist without the DEXCR, grouping them
is OK. Could be called NT_PPC_DEXCF (F for facility) ?

See NT_PPC_PKEY for an example.

I know HASHKEYR is security sensitive, but I think the existing ptrace
checks should be sufficient. A ptracer has more or less full control of
the tracee anyway.

To support checkpoint/restore we'd need to support setting NPHIE in the
DEXCR via ptrace. I think for starters we can just fail the ->set() if
the DEXCR doesn't match the current SPR value.

cheers