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=-8.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,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 7A386C433E0 for ; Wed, 24 Jun 2020 07:15:24 +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 3A74C207DD for ; Wed, 24 Jun 2020 07:15:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="mIuK1pOw" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3A74C207DD 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-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=HoWQgO9vGf2pgK4I/PZElPw7DUKjZXkEoQecjnPdW7w=; b=mIuK1pOwGQfBy3v+q0C5B0RPK WtHMmQKjDs3WpTA3YwTSlpwwTeYEp52iKMnDkvEAvaBqvqz6DiYA6go55I/KqRgfEMR4n/Z3bue2H 0WpFpReYOMHQYtHYK2aK9uhKvinJeNHuvZyVJl7Y2AbbHqE4hry7vIE6pm//wzaFBahxV1EgItOQt QbFeFsSd1C+Vwh2wgaONdIXZFnEh7ophSqS5ESg7rNQhfylQTScvNG9o0AVLWJDmk1lcHNcFLB9xI jlvm2h593Sbr8dXg1ClmgNgFRK1kfC7ivA9I2CtR18MhQHcQJfwXo7R58FggA6E/5N5ukE9s4eQD+ nwWDETbjw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jnzb8-000849-6F; Wed, 24 Jun 2020 07:13:30 +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 1jnzb4-00083G-RY for linux-arm-kernel@lists.infradead.org; Wed, 24 Jun 2020 07:13:27 +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 95C1B1F1; Wed, 24 Jun 2020 00:13:25 -0700 (PDT) Received: from [10.57.20.252] (unknown [10.57.20.252]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9A96D3F73C; Wed, 24 Jun 2020 00:13:22 -0700 (PDT) Subject: Re: [PATCH v3 2/3] arm64: cpufeature: Modify address authentication cpufeature to exact To: Dave Martin , Catalin Marinas , Will Deacon 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> <20200623144749.GZ25945@arm.com> From: Amit Daniel Kachhap Message-ID: Date: Wed, 24 Jun 2020 12:43:20 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200623144749.GZ25945@arm.com> Content-Language: en-US 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 , Kristina Martsenko , Mark Brown , James Morse , Vincenzo Frascino , linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 6/23/20 8:17 PM, Dave Martin wrote: > 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. Yes It makes to add this patch to the stable version. @Catalin, @Will - Shall I send this one with a fix subject line? Please let me know your suggestion. >>> >>> 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? oops I missed this one. > > [...] > > Cheers > ---Dave > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel