linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Dave Martin <Dave.Martin@arm.com>
Cc: linux-kernel@vger.kernel.org, "Andrew Jones" <drjones@redhat.com>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Eugene Syromiatnikov" <esyr@redhat.com>,
	"Florian Weimer" <fweimer@redhat.com>,
	"H.J. Lu" <hjl.tools@gmail.com>, "Jann Horn" <jannh@google.com>,
	"Kees Cook" <keescook@chromium.org>,
	"Kristina Martšenko" <kristina.martsenko@arm.com>,
	"Mark Brown" <broonie@kernel.org>,
	"Paul Elliott" <paul.elliott@arm.com>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"Sudakshina Das" <sudi.das@arm.com>,
	"Szabolcs Nagy" <szabolcs.nagy@arm.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Will Deacon" <will.deacon@arm.com>,
	"Yu-cheng Yu" <yu-cheng.yu@intel.com>,
	"Amit Kachhap" <amit.kachhap@arm.com>,
	"Vincenzo Frascino" <vincenzo.frascino@arm.com>,
	linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 05/12] arm64: Basic Branch Target Identification support
Date: Fri, 11 Oct 2019 16:10:29 +0100	[thread overview]
Message-ID: <20191011151028.GE33537@lakrids.cambridge.arm.com> (raw)
In-Reply-To: <1570733080-21015-6-git-send-email-Dave.Martin@arm.com>

On Thu, Oct 10, 2019 at 07:44:33PM +0100, Dave Martin wrote:
> This patch adds the bare minimum required to expose the ARMv8.5
> Branch Target Identification feature to userspace.
> 
> By itself, this does _not_ automatically enable BTI for any initial
> executable pages mapped by execve().  This will come later, but for
> now it should be possible to enable BTI manually on those pages by
> using mprotect() from within the target process.
> 
> Other arches already using the generic mman.h are already using
> 0x10 for arch-specific prot flags, so we use that for PROT_BTI
> here.
> 
> For consistency, signal handler entry points in BTI guarded pages
> are required to be annotated as such, just like any other function.
> This blocks a relatively minor attack vector, but comforming
> userspace will have the annotations anyway, so we may as well
> enforce them.
> 
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> 
> ---
> 
> Changes since v1:
> 
>  * Configure SCTLR_EL1.BTx to disallow BR onto a PACIxSP instruction
>    (except via X16/X17):
> 
>    The AArch64 procedure call standard requires binaries marked with
>    GNU_PROPERTY_AARCH64_FEATURE_1_BTI to use X16/X17 in trampolines
>    and tail calls, so it makes no sense to be permissive.
> 
>  * Rename PROT_BTI_GUARDED to PROT_BTI.
> 
>  * Rename VM_ARM64_GP to VM_ARM64_BTI:
> 
>    Although the architectural name for the BTI page table bit is "GP",
>    BTI is nonetheless the feature it controls.  So avoid introducing
>    the "GP" naming just for this -- it's just an unecessary extra
>    source of confusion.
> 
>  * Tidy up masking with ~PSR_BTYPE_MASK.
> 
>  * Drop masking out of BTYPE on SVC, with a comment outlining why.
> 
>  * Split PSR_BTYPE_SHIFT definition into this patch.  It's not
>    useful yet, but it makes sense to define PSR_BTYPE_* using this
>    from the outset.
> 
>  * Migrate to ct_user_exit_irqoff in entry.S:el0_bti.

[...]

> diff --git a/arch/arm64/include/asm/mman.h b/arch/arm64/include/asm/mman.h
> new file mode 100644
> index 0000000..cbfe3238
> --- /dev/null
> +++ b/arch/arm64/include/asm/mman.h
> @@ -0,0 +1,33 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef __ASM_MMAN_H__
> +#define __ASM_MMAN_H__
> +
> +#include <uapi/asm/mman.h>
> +
> +#define arch_calc_vm_prot_bits(prot, pkey) arm64_calc_vm_prot_bits(prot)
> +static inline unsigned long arm64_calc_vm_prot_bits(unsigned long prot)
> +{
> +	if (system_supports_bti() && (prot & PROT_BTI))
> +		return VM_ARM64_BTI;
> +
> +	return 0;
> +}

Can we call this arch_calc_vm_prot_bits() directly, with all the
arguments:

static inline unsigned long arch_calc_vm_prot_bits(unsigned long prot,
						   unsigned long pkey)
{
	...
}
#define arch_calc_vm_prot_bits arch_calc_vm_prot_bits

... as that makes it a bit easier to match definition with use, and just
definign the name makes it a bit clearer that that's probably for the
benefit of some ifdeffery.

Likewise for the other functions here.

> +#define arch_vm_get_page_prot(vm_flags) arm64_vm_get_page_prot(vm_flags)
> +static inline pgprot_t arm64_vm_get_page_prot(unsigned long vm_flags)
> +{
> +	return (vm_flags & VM_ARM64_BTI) ? __pgprot(PTE_GP) : __pgprot(0);
> +}
> +
> +#define arch_validate_prot(prot, addr) arm64_validate_prot(prot, addr)
> +static inline int arm64_validate_prot(unsigned long prot, unsigned long addr)
> +{
> +	unsigned long supported = PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM;
> +
> +	if (system_supports_bti())
> +		supported |= PROT_BTI;
> +
> +	return (prot & ~supported) == 0;
> +}

If we have this check, can we ever get into arm64_calc_vm_prot_bits()
with PROT_BIT but !system_supports_bti()?

... or can that become:

	return (prot & PROT_BTI) ? VM_ARM64_BTI : 0;

> +#endif /* ! __ASM_MMAN_H__ */
> diff --git a/arch/arm64/include/asm/pgtable-hwdef.h b/arch/arm64/include/asm/pgtable-hwdef.h
> index 3df60f9..f85d1fc 100644
> --- a/arch/arm64/include/asm/pgtable-hwdef.h
> +++ b/arch/arm64/include/asm/pgtable-hwdef.h
> @@ -150,6 +150,7 @@
>  #define PTE_SHARED		(_AT(pteval_t, 3) << 8)		/* SH[1:0], inner shareable */
>  #define PTE_AF			(_AT(pteval_t, 1) << 10)	/* Access Flag */
>  #define PTE_NG			(_AT(pteval_t, 1) << 11)	/* nG */
> +#define PTE_GP			(_AT(pteval_t, 1) << 50)	/* BTI guarded */

As a heads-up for anyone looking at the latest ARM ARM (ARM DDI
0487E.a), GP is missing from some of the descriptions of the table
formats in section D5.3.1 in the latest ARM ARM (ARM DDI 0487E.a), which
imply it's RES0.

It looks like that'll be fixed for the next release.

[...]

> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index 84a8227..6c5adea 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -737,6 +737,8 @@ el0_sync:
>  	b.eq	el0_pc
>  	cmp	x24, #ESR_ELx_EC_UNKNOWN	// unknown exception in EL0
>  	b.eq	el0_undef
> +	cmp	x24, #ESR_ELx_EC_BTI		// branch target exception
> +	b.eq	el0_bti
>  	cmp	x24, #ESR_ELx_EC_BREAKPT_LOW	// debug exception in EL0
>  	b.ge	el0_dbg
>  	b	el0_inv
> @@ -887,6 +889,15 @@ el0_undef:
>  	mov	x0, sp
>  	bl	do_undefinstr
>  	b	ret_to_user
> +el0_bti:
> +	/*
> +	 * Branch target exception
> +	 */
> +	ct_user_exit_irqoff
> +	enable_daif
> +	mov	x0, sp
> +	bl	do_bti
> +	b	ret_to_user

As a heads-up, this'll conflict with James's conversion of the sync
entry points to C.

> diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
> index dd2cdc0..4a3bd32 100644
> --- a/arch/arm64/kernel/signal.c
> +++ b/arch/arm64/kernel/signal.c
> @@ -730,6 +730,11 @@ static void setup_return(struct pt_regs *regs, struct k_sigaction *ka,
>  	regs->regs[29] = (unsigned long)&user->next_frame->fp;
>  	regs->pc = (unsigned long)ka->sa.sa_handler;
>  
> +	if (system_supports_bti()) {
> +		regs->pstate &= ~PSR_BTYPE_MASK;
> +		regs->pstate |= PSR_BTYPE_CALL;
> +	}
> +

I think we might need a comment as to what we're trying to ensure here.

I was under the (perhaps mistaken) impression that we'd generate a
pristine pstate for a signal handler, and it's not clear to me that we
must ensure the first instruction is a target instruction.

[...]

> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> index 34739e8..15e3c4f 100644
> --- a/arch/arm64/kernel/traps.c
> +++ b/arch/arm64/kernel/traps.c
> @@ -406,6 +406,12 @@ asmlinkage void __exception do_undefinstr(struct pt_regs *regs)
>  	force_signal_inject(SIGILL, ILL_ILLOPC, regs->pc);
>  }
>  
> +asmlinkage void __exception do_bti(struct pt_regs *regs)
> +{
> +	BUG_ON(!user_mode(regs));
> +	force_signal_inject(SIGILL, ILL_ILLOPC, regs->pc);
> +}

This was only wired up into the EL0 sync entry paths, so I think we can
drop the BUG_ON() -- we don't have similar in other EL0-only paths.

Thanks,
Mark.

  parent reply	other threads:[~2019-10-11 15:10 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-10 18:44 [PATCH v2 00/12] arm64: ARMv8.5-A: Branch Target Identification support Dave Martin
2019-10-10 18:44 ` [PATCH v2 01/12] ELF: UAPI and Kconfig additions for ELF program properties Dave Martin
2019-10-10 18:44 ` [PATCH v2 02/12] ELF: Add ELF program property parsing support Dave Martin
2019-10-10 18:44 ` [PATCH v2 03/12] mm: Reserve asm-generic prot flag 0x10 for arch use Dave Martin
2019-10-10 18:44 ` [PATCH v2 04/12] arm64: docs: cpu-feature-registers: Document ID_AA64PFR1_EL1 Dave Martin
2019-10-11 13:19   ` Alex Bennée
2019-10-11 14:51     ` Dave Martin
2019-10-21 19:18       ` Mark Brown
2019-10-22 10:32         ` Will Deacon
2019-10-10 18:44 ` [PATCH v2 05/12] arm64: Basic Branch Target Identification support Dave Martin
2019-10-11 15:06   ` [FIXUP 0/2] Fixups to patch 5 Dave Martin
2019-10-11 15:06     ` [FIXUP 1/2] squash! arm64: Basic Branch Target Identification support Dave Martin
2019-10-11 15:06     ` [FIXUP 2/2] " Dave Martin
2019-10-11 15:10   ` Mark Rutland [this message]
2019-10-11 15:25     ` [PATCH v2 05/12] " Richard Henderson
2019-10-11 15:32       ` Dave Martin
2019-10-11 15:40         ` Mark Rutland
2019-10-11 15:44           ` Dave Martin
2019-10-11 16:01             ` Dave Martin
2019-10-11 16:42               ` Dave Martin
2019-10-18 11:05                 ` Mark Rutland
2019-10-18 13:36                   ` Dave Martin
2019-10-11 17:20     ` Dave Martin
2019-10-18 11:10       ` Mark Rutland
2019-10-18 13:37         ` Dave Martin
2019-10-18 11:16       ` Mark Rutland
2019-10-18 13:40         ` Dave Martin
2019-10-10 18:44 ` [PATCH v2 06/12] elf: Allow arch to tweak initial mmap prot flags Dave Martin
2019-10-10 18:44 ` [PATCH v2 07/12] arm64: elf: Enable BTI at exec based on ELF program properties Dave Martin
2019-10-10 18:44 ` [PATCH v2 08/12] arm64: BTI: Decode BYTPE bits when printing PSTATE Dave Martin
2019-10-11 15:31   ` Richard Henderson
2019-10-11 15:33     ` Dave Martin
2019-10-10 18:44 ` [PATCH v2 09/12] arm64: traps: Fix inconsistent faulting instruction skipping Dave Martin
2019-10-11 15:24   ` Mark Rutland
2019-10-15 15:21     ` Dave Martin
2019-10-15 16:42       ` Mark Rutland
2019-10-15 16:49         ` Dave Martin
2019-10-18 16:40           ` Dave Martin
2019-10-22 11:09             ` Robin Murphy
2019-10-10 18:44 ` [PATCH v2 10/12] arm64: traps: Shuffle code to eliminate forward declarations Dave Martin
2019-10-10 18:44 ` [PATCH v2 11/12] arm64: BTI: Reset BTYPE when skipping emulated instructions Dave Martin
2019-10-11 14:21   ` Mark Rutland
2019-10-11 14:47     ` Dave Martin
2019-10-18 11:04       ` Mark Rutland
2019-10-18 14:49         ` Dave Martin
2019-10-10 18:44 ` [PATCH v2 12/12] KVM: " Dave Martin
2019-10-11 14:24   ` Mark Rutland
2019-10-11 14:44     ` Dave Martin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191011151028.GE33537@lakrids.cambridge.arm.com \
    --to=mark.rutland@arm.com \
    --cc=Dave.Martin@arm.com \
    --cc=amit.kachhap@arm.com \
    --cc=arnd@arndb.de \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=drjones@redhat.com \
    --cc=esyr@redhat.com \
    --cc=fweimer@redhat.com \
    --cc=hjl.tools@gmail.com \
    --cc=jannh@google.com \
    --cc=keescook@chromium.org \
    --cc=kristina.martsenko@arm.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paul.elliott@arm.com \
    --cc=peterz@infradead.org \
    --cc=richard.henderson@linaro.org \
    --cc=sudi.das@arm.com \
    --cc=szabolcs.nagy@arm.com \
    --cc=tglx@linutronix.de \
    --cc=vincenzo.frascino@arm.com \
    --cc=will.deacon@arm.com \
    --cc=yu-cheng.yu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).