linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Martin <Dave.Martin@arm.com>
To: linux-kernel@vger.kernel.org
Cc: "Amit Kachhap" <amit.kachhap@arm.com>,
	"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>,
	"Marc Zyngier" <maz@kernel.org>,
	"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>,
	"Suzuki Poulose" <suzuki.poulose@arm.com>,
	"Szabolcs Nagy" <szabolcs.nagy@arm.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Vincenzo Frascino" <vincenzo.frascino@arm.com>,
	"Will Deacon" <will@kernel.org>,
	"Yu-cheng Yu" <yu-cheng.yu@intel.com>,
	linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: [FIXUP 2/2] squash! arm64: Basic Branch Target Identification support
Date: Fri, 11 Oct 2019 16:06:29 +0100	[thread overview]
Message-ID: <1570806389-16014-3-git-send-email-Dave.Martin@arm.com> (raw)
In-Reply-To: <1570806389-16014-1-git-send-email-Dave.Martin@arm.com>

[Add Kconfig dependency on CONFIG_ARM64_PTR_AUTH]

Signed-off-by: Dave Martin <Dave.Martin@arm.com>

---

This one could use some discussion.

Two conforming hardware implementations containing BTI could nonetheless
have incompatible Pointer auth implementations, meaning that we expose
BTI to userspace but not Pointer auth.

That's stupid hardware design, but the architecture doesn't forbid it
today.  We _could_ detect this and hide BTI from userspace too, but
if a big.LITTLE system contains Pointer auth implementations with
mismatched IMP DEF algorithms, we lose -- we have no direct way to
detect that.

Since BTI still provides some limited value without Pointer auth,
disabling it unnecessarily might be regarded as too heavy-handed.

Changes since v2:

 * Depend on CONFIG_ARM64_PTR_AUTH=y.

   During test hacking, I observed that there are situations where
   userspace should be entitled to assume that Pointer auth is present
   if BTI is present.

   Although the kernel BTI support doesn't require any aspect of
   Pointer authentication, there are architectural dependencies:

    * ARMv8.5 requires BTI to be implemented. [1]
    * BTI requires ARMv8.4-A to be implemented. [1], [2]
    * ARMv8.4 requires ARMv8.3 to be implemented. [3]
    * ARMv8.3 requires Pointer authentication to be implemented. [4]

   i.e., an implementation that supports BTI but not Pointer auth is
   broken.

   BTI is also designed to be complementary to Pointer authentication:
   without Pointer auth, BTI would offer no protection for function
   returns, seriously undermining the value of the feature.

   See ARM ARM for ARMv8-A (ARM DDI 0487E.a) Sections:

   [1] A2.8.1, "Architectural features added by ARMv8.5"

   [2] A2.2.1, "Permitted implementation of subsets of ARMv8.x and
       ARMv8.(x+1) architectural features"

   [3] A2.6.1, "Architectural features added by Armv8.3"

   [4] A2.6, "The Armv8.3 architecture extension"
---
 arch/arm64/Kconfig | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 6e26b72..a64d91d 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1418,16 +1418,21 @@ menu "ARMv8.5 architectural features"
 config ARM64_BTI
 	bool "Branch Target Identification support"
 	default y
+	depends on ARM64_PTR_AUTH
 	help
 	  Branch Target Identification (part of the ARMv8.5 Extensions)
 	  provides a mechanism to limit the set of locations to which computed
 	  branch instructions such as BR or BLR can jump.
 
-	  This is intended to provide complementary protection to other control
+	  To make use of BTI on CPUs that support it, say Y.
+
+	  BTI is intended to provide complementary protection to other control
 	  flow integrity protection mechanisms, such as the Pointer
 	  authentication mechanism provided as part of the ARMv8.3 Extensions.
+	  For this reason, it does not make sense to enable this option without
+	  also enabling support for Pointer authentication.
 
-	  To make use of BTI on CPUs that support it, say Y.
+	  Thus, to enable this option you also need to select ARM64_PTR_AUTH=y.
 
 	  Userspace binaries must also be specifically compiled to make use of
 	  this mechanism.  If you say N here or the hardware does not support
-- 
2.1.4


  parent reply	other threads:[~2019-10-11 15:07 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     ` Dave Martin [this message]
2019-10-11 15:10   ` [PATCH v2 05/12] " Mark Rutland
2019-10-11 15:25     ` 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=1570806389-16014-3-git-send-email-Dave.Martin@arm.com \
    --to=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=maz@kernel.org \
    --cc=paul.elliott@arm.com \
    --cc=peterz@infradead.org \
    --cc=richard.henderson@linaro.org \
    --cc=sudi.das@arm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=szabolcs.nagy@arm.com \
    --cc=tglx@linutronix.de \
    --cc=vincenzo.frascino@arm.com \
    --cc=will@kernel.org \
    --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).