From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 60747C433E0 for ; Tue, 23 Jun 2020 14:49:35 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 24F8220720 for ; Tue, 23 Jun 2020 14:49:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="1pF4W9Gv" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 24F8220720 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=jy3cTSa9DyXjVKdLm1njoREMZYjfaeglk/fj5vsepKo=; b=1pF4W9GvwvG7531/NZKG+DiLg qa1mmXO+3XWDijII2SGsvDHNF5ZJE+H9tUaujc/2IqBAoqHWjyYrgIWVCHWuFk3FWUCpb6n7oZySN CvfEDznsGG56IxUD95hg8S90L2gkfR+pGU4KFUPcXoztJw/3EckhKcr1tyAkvw+poTIG3X5JueU36 9xTosopDO0WmmYSiGc/mi5xxbD1kJgvbdbr3g1z68zLZ1sQiDGreX4yrTXX+kix0hKi9vWXBS/RW4 Oq3Vtg/q1XiPZRrcY032LPs8SJGa1CQrt6BVW2gSM3RF6/flHJyMW/Cwfesokz/SPtZelVmOMy8a3 5G3R4ZrxQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jnkDM-0000wK-Rz; Tue, 23 Jun 2020 14:47:56 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jnkDJ-0000vb-Kn for linux-arm-kernel@lists.infradead.org; Tue, 23 Jun 2020 14:47:54 +0000 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 3B48331B; Tue, 23 Jun 2020 07:47:53 -0700 (PDT) Received: from arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C5D4A3F6CF; Tue, 23 Jun 2020 07:47:51 -0700 (PDT) Date: Tue, 23 Jun 2020 15:47:49 +0100 From: Dave Martin To: Amit Daniel Kachhap Subject: Re: [PATCH v3 2/3] arm64: cpufeature: Modify address authentication cpufeature to exact Message-ID: <20200623144749.GZ25945@arm.com> References: <1592457029-18547-1-git-send-email-amit.kachhap@arm.com> <1592457029-18547-3-git-send-email-amit.kachhap@arm.com> <20200622143503.GT25945@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Kees Cook , Suzuki K Poulose , Catalin Marinas , Kristina Martsenko , Mark Brown , James Morse , Vincenzo Frascino , Will Deacon , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Jun 23, 2020 at 06:47:02PM +0530, Amit Daniel Kachhap wrote: > Hi, > > On 6/22/20 8:05 PM, Dave Martin wrote: > >On Thu, Jun 18, 2020 at 10:40:28AM +0530, Amit Daniel Kachhap wrote: > >>This patch modifies the address authentication cpufeature type to EXACT > >>from earlier LOWER_SAFE as the different configurations added for Armv8.6 > >>enhanced PAC have different behaviour and there is no tunable to enable the > >>lower safe versions. > > > >The enancements add no new instructions at EL0, right? And no > >behavioural change, provided that userspace doesn't care what signing/ > >authentication algorithm is used? > > Yes you are correct that no new instructions are added. > > > > >If so then I guess you're correct not to add a new hwcap, but I thought > >it was worth asking. > > > >>non-exact secondary cpus but rather marks them as tainted. This patch fixes > >>it by replacing the generic match handler with a new handler specific to > >>ptrauth. > >> > >>After this change, if there is any variation in ptrauth configurations in > >>secondary cpus from boot cpu then those mismatched cpus are parked in an > >>infinite loop. > >> > >>Signed-off-by: Amit Daniel Kachhap > >>[Suzuki: Introduce new matching function for address authentication] > >>Suggested-by: Suzuki K Poulose > > > >Does a corresponding patch need to go to stable? As things stand, I > >think older kernels that support pointer auth will go wrong on v8.7+ > >hardware that has these features. > > > >This patch in its current form may be too heavy for stable, though. > > > >See comment below though. > > > >>--- > >>Change since v2: > >> * Added new matching helper function has_address_auth_cpucap as address > >> authentication cpufeature is now FTR_EXACT. The existing matching function > >> has_cpuid_feature is specific to LOWER_SAFE. > >> > >> arch/arm64/kernel/cpufeature.c | 56 ++++++++++++++++++++++++++++------ > >> 1 file changed, 47 insertions(+), 9 deletions(-) > >> > >>diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c > >>index 4ae41670c2e6..42670d615555 100644 > >>--- a/arch/arm64/kernel/cpufeature.c > >>+++ b/arch/arm64/kernel/cpufeature.c > >>@@ -210,9 +210,9 @@ static const struct arm64_ftr_bits ftr_id_aa64isar1[] = { > >> ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR1_FCMA_SHIFT, 4, 0), > >> ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR1_JSCVT_SHIFT, 4, 0), > >> ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_PTR_AUTH), > >>- FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR1_API_SHIFT, 4, 0), > >>+ FTR_STRICT, FTR_EXACT, ID_AA64ISAR1_API_SHIFT, 4, 0), > >> ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_PTR_AUTH), > >>- FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR1_APA_SHIFT, 4, 0), > >>+ FTR_STRICT, FTR_EXACT, ID_AA64ISAR1_APA_SHIFT, 4, 0), > >> ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR1_DPB_SHIFT, 4, 0), > >> ARM64_FTR_END, > >> }; > >>@@ -1601,11 +1601,49 @@ static void cpu_clear_disr(const struct arm64_cpu_capabilities *__unused) > >> #endif /* CONFIG_ARM64_RAS_EXTN */ > >> #ifdef CONFIG_ARM64_PTR_AUTH > >>-static bool has_address_auth(const struct arm64_cpu_capabilities *entry, > >>- int __unused) > >>+static bool has_address_auth_cpucap(const struct arm64_cpu_capabilities *entry, int scope) > >> { > >>- return __system_matches_cap(ARM64_HAS_ADDRESS_AUTH_ARCH) || > >>- __system_matches_cap(ARM64_HAS_ADDRESS_AUTH_IMP_DEF); > >>+ int local_cpu_auth; > >>+ static int boot_cpu_auth_arch; > >>+ static int boot_cpu_auth_imp_def; > >>+ > >>+ /* We don't expect to be called with SCOPE_SYSTEM */ > >>+ WARN_ON(scope == SCOPE_SYSTEM); > >>+ > >>+ local_cpu_auth = cpuid_feature_extract_field(__read_sysreg_by_encoding(entry->sys_reg), > >>+ entry->field_pos, entry->sign); > >>+ /* > >>+ * The ptr-auth feature levels are not intercompatible with > >>+ * lower levels. Hence we must match all the CPUs with that > >>+ * of the boot CPU. So cache the level of boot CPU and compare > >>+ * it against the secondary CPUs. > >>+ */ > > > >Thinking about this, does it actually matter if different CPUs have > >different trapping behaviours for ptrauth? > > > >If we are guaranteed that the signing algorithm is still compatible > >across all CPUs, we might get away with it. > > You may be right that these protections may not be required practically. > But the algorithm of each configurations is different so theoretically > same set of software will produce different behavior on different cpus. > > This code initially changed only FTR_EXACT from FTR_LOWE_SAFE. But there > are many issues identified here [1] in the cpufeature framework so rest > of the defensive changes added. > > [1]: https://www.spinics.net/lists/arm-kernel/msg808238.html > > > >Possibly a dumb question -- I haven't checked the specs to find out > >whether this makes any sense or not. > > Your point is valid though. OK. Did you see my comment above about patches for stable? [...] Cheers ---Dave _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel