Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp1043677ybp; Fri, 11 Oct 2019 08:10:44 -0700 (PDT) X-Google-Smtp-Source: APXvYqyZ2PSAKkRWNZb6ywUWpkOkiqZ5PW5kw7bHEFae+tBNKPO8JltVLfDOmMpb+W3U+EnWLANi X-Received: by 2002:a17:906:9246:: with SMTP id c6mr14164620ejx.64.1570806644551; Fri, 11 Oct 2019 08:10:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570806644; cv=none; d=google.com; s=arc-20160816; b=O4oX7dWvMexGsOoHbHNgrXj+tVlhisFwZzZnDIwnKcaCHbw97YyOsE5tDzC7ffTP/Q uPr3ddAxpShOPDiM4VSzMU1YtiLoPndCUzOK1LxnP9Oei8p0o8wWlDEYptnvBnAq7aOh im3DI7GFG+OtI7oymVQRGFfPeZ4gJuNvACRMX2lK2V1Wb7wQtlr+IzUY5JbWRgvCnLmG MlVt8lIRh+HRMznneO8NTMyley3UrYCRlNX5qkf/miJdSU0kDlxewKIApF7997idp6x5 wOATBMAP3Qpl/JLOh1ixXj1u9S8OylDBfJW3NxDauNQj1LV3k63tc4YbT4IuE1I/4Ooa 1xFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=IC8KyDZTrciYl+VB/roz1HVLWFDLOeaP1QagINOkQpQ=; b=kZ/BB+0prT4ySUc9bfoMbsDlUV2DxMIi9mstcEqDv/zC9J5cVXoRuwFjHP35eCQoqg SfXc7S8Ewc0LfJ27j1pD18oLwwccbH98aUxlbN35VUMJGLvNRsbX2SEgiMcNETtrM0Ce +lBWyUWeXAtJRSy5TMn9pGhIvDMZQBybdFJUy8j7D2LNe0ye5sPpOdXs25xZbKYG2hVQ 9FBFAjqp+3J1Gx6X1za8Y0xRZFcFpafHvNdyDIuI66sVx0lLfajLcpjYgVwr1I+aNs9O FRXYmQn99uczvwz7iv5Id4OgO2B+wSK8VrlD4lbbxG45qHTBgzrSkiliXC4uHtzoeY8r RuBw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x30si6294439edi.351.2019.10.11.08.10.21; Fri, 11 Oct 2019 08:10:44 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728096AbfJKPHY (ORCPT + 99 others); Fri, 11 Oct 2019 11:07:24 -0400 Received: from foss.arm.com ([217.140.110.172]:35242 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726332AbfJKPHX (ORCPT ); Fri, 11 Oct 2019 11:07:23 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D54291570; Fri, 11 Oct 2019 08:07:22 -0700 (PDT) Received: from e103592.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id EDF4D3F68E; Fri, 11 Oct 2019 08:07:19 -0700 (PDT) From: Dave Martin To: linux-kernel@vger.kernel.org Cc: Amit Kachhap , Andrew Jones , Arnd Bergmann , Catalin Marinas , Eugene Syromiatnikov , Florian Weimer , "H.J. Lu" , Jann Horn , Kees Cook , =?UTF-8?q?Kristina=20Mart=C5=A1enko?= , Marc Zyngier , Mark Brown , Paul Elliott , Peter Zijlstra , Richard Henderson , Sudakshina Das , Suzuki Poulose , Szabolcs Nagy , Thomas Gleixner , Vincenzo Frascino , Will Deacon , Yu-cheng Yu , 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 Message-Id: <1570806389-16014-3-git-send-email-Dave.Martin@arm.com> X-Mailer: git-send-email 2.1.4 In-Reply-To: <1570806389-16014-1-git-send-email-Dave.Martin@arm.com> References: <1570733080-21015-6-git-send-email-Dave.Martin@arm.com> <1570806389-16014-1-git-send-email-Dave.Martin@arm.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [Add Kconfig dependency on CONFIG_ARM64_PTR_AUTH] Signed-off-by: Dave Martin --- 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