linux-kernel - Re: [RFC 7/9] arm64: expose PAC bit positions via ptrace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170725121145.GB6321@e103592.cambridge.arm.com>
Date:   Tue, 25 Jul 2017 13:11:48 +0100
From:   Dave Martin <Dave.Martin@....com>
To:     Mark Rutland <mark.rutland@....com>
Cc:     linux-arm-kernel@...ts.infradead.org, linux-arch@...r.kernel.org,
        arnd@...db.de, jiong.wang@....com, marc.zyngier@....com,
        catalin.marinas@....com, suzuki.poulose@....com,
        will.deacon@....com, linux-kernel@...r.kernel.org,
        kvmarm@...ts.cs.columbia.edu, christoffer.dall@...aro.org
Subject: Re: [RFC 7/9] arm64: expose PAC bit positions via ptrace

On Mon, Apr 03, 2017 at 04:19:23PM +0100, Mark Rutland wrote:
> When pointer authentication is in use, data/instruction pointers have a
> number of PAC bits inserted into them. The number and position of these
> bits depends on the configured TCR_ELx.TxSZ and whether tagging is
> enabled. ARMv8.3 allows tagging to differ for instruction and data
> pointers.
> 
> For userspace debuggers to unwind the stack and/or to follow pointer
> chains, they need to be able to remove the PAC bits before attempting to
> use a pointer.
> 
> This patch adds a new structure with masks describing the location of
> PAC bits in instruction and data pointers, which userspace can query via
> PTRACE_GETREGSET. By clearing these bits from pointers, userspace can
> acquire the PAC-less versions.
> 
> This new regset is exposed when the kernel is built with (user) pointer
> authentication support, and the feature is enabled.  Otherwise, it is
> hidden.
> 
> Note that even if the feature is available and enabled, we cannot
> determine whether userspace is making use of the feature, so debuggers
> need to cope with this case regardless.
> 
> Signed-off-by: Mark Rutland <mark.rutland@....com>
> Cc: Catalin Marinas <catalin.marinas@....com>
> Cc: Jiong Wang <jiong.wang@....com>
> Cc: Will Deacon <will.deacon@....com>
> ---
>  arch/arm64/include/asm/pointer_auth.h |  8 +++++++
>  arch/arm64/include/uapi/asm/ptrace.h  |  5 +++++
>  arch/arm64/kernel/ptrace.c            | 39 +++++++++++++++++++++++++++++++++++
>  include/uapi/linux/elf.h              |  1 +
>  4 files changed, 53 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/pointer_auth.h b/arch/arm64/include/asm/pointer_auth.h
> index 345df24..ed505fe 100644
> --- a/arch/arm64/include/asm/pointer_auth.h
> +++ b/arch/arm64/include/asm/pointer_auth.h
> @@ -16,9 +16,11 @@
>  #ifndef __ASM_POINTER_AUTH_H
>  #define __ASM_POINTER_AUTH_H
>  
> +#include <linux/bitops.h>
>  #include <linux/random.h>
>  
>  #include <asm/cpufeature.h>
> +#include <asm/memory.h>
>  #include <asm/sysreg.h>
>  
>  #ifdef CONFIG_ARM64_POINTER_AUTHENTICATION
> @@ -70,6 +72,12 @@ static inline void ptrauth_keys_dup(struct ptrauth_keys *old,
>  	*new = *old;
>  }
>  
> +/*
> + * The pointer bits used by a pointer authentication code.
> + * If we were to use tagged pointers, bits 63:56 would also apply.
> + */
> +#define ptrauth_pac_mask() 	GENMASK(54, VA_BITS)

Tagged pointers _are_ enabled for userspace by default, no?

[...]

> diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
> index b59ee07..cae3d1e 100644
> --- a/include/uapi/linux/elf.h
> +++ b/include/uapi/linux/elf.h
> @@ -414,6 +414,7 @@
>  #define NT_ARM_HW_BREAK	0x402		/* ARM hardware breakpoint registers */
>  #define NT_ARM_HW_WATCH	0x403		/* ARM hardware watchpoint registers */
>  #define NT_ARM_SYSTEM_CALL	0x404	/* ARM system call number */
> +#define NT_ARM_PAC_MASK		0x405	/* ARM pointer authentication code masks */

The is the value tentatively assigned to NT_ARM_SVE.

Cheers
---Dave