Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1695671 > unrolled thread

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

Started byDave Martin <Dave.Martin@arm.com>
First post2017-07-25 14:20 +0200
Last post2017-07-25 17:10 +0200
Articles 3 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [RFC 7/9] arm64: expose PAC bit positions via ptrace Dave Martin <Dave.Martin@arm.com> - 2017-07-25 14:20 +0200
    Re: [RFC 7/9] arm64: expose PAC bit positions via ptrace Dave Martin <Dave.Martin@arm.com> - 2017-07-25 17:10 +0200
    Re: [RFC 7/9] arm64: expose PAC bit positions via ptrace Mark Rutland <mark.rutland@arm.com> - 2017-07-25 17:10 +0200

#1695671 — Re: [RFC 7/9] arm64: expose PAC bit positions via ptrace

FromDave Martin <Dave.Martin@arm.com>
Date2017-07-25 14:20 +0200
SubjectRe: [RFC 7/9] arm64: expose PAC bit positions via ptrace
Message-ID<u76YG-2Fx-5@gated-at.bofh.it>
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@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Jiong Wang <jiong.wang@arm.com>
> Cc: Will Deacon <will.deacon@arm.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

[toc] | [next] | [standalone]


#1695824

FromDave Martin <Dave.Martin@arm.com>
Date2017-07-25 17:10 +0200
Message-ID<u79Dd-4o6-33@gated-at.bofh.it>
In reply to#1695671
On Tue, Jul 25, 2017 at 03:59:04PM +0100, Mark Rutland wrote:
> On Tue, Jul 25, 2017 at 01:11:48PM +0100, Dave Martin wrote:
> > On Mon, Apr 03, 2017 at 04:19:23PM +0100, Mark Rutland wrote:
> > > +/*
> > > + * 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?
> 
> Yes; I'd meant s/tagged/untagged/.
> 
> I've corrected this to:
> 
> /*
>  * The EL0 pointer bits used by a pointer authentication code.
>  * This is dependent on TBI0 being enabled, or bits 63:56 would also apply.
>  */

Yes, that's better.  If we do enable untagged pointers for userspace at
some point though, this is likely to be missed.

I don't have a good answer to this.

> > > 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.
> 
> I must've generated this patch before I corrected this; my local branch
> (and kernel.org) have 0x406 here.
> 
> Sorry about that.

Shame, I had a rant about pragmatism prepped and ready ;)

Cheers
---Dave

[toc] | [prev] | [next] | [standalone]


#1695825

FromMark Rutland <mark.rutland@arm.com>
Date2017-07-25 17:10 +0200
Message-ID<u79Dd-4o6-35@gated-at.bofh.it>
In reply to#1695671
On Tue, Jul 25, 2017 at 01:11:48PM +0100, Dave Martin wrote:
> On Mon, Apr 03, 2017 at 04:19:23PM +0100, Mark Rutland wrote:
> > +/*
> > + * 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?

Yes; I'd meant s/tagged/untagged/.

I've corrected this to:

/*
 * The EL0 pointer bits used by a pointer authentication code.
 * This is dependent on TBI0 being enabled, or bits 63:56 would also apply.
 */

> > 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.

I must've generated this patch before I corrected this; my local branch
(and kernel.org) have 0x406 here.

Sorry about that.

Mark.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web