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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0F160C433EF for ; Wed, 20 Apr 2022 10:19:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=IGWJLoaH/AuUHrCxAkohX6O0Op/zPjd+mXhsjmyAkbc=; b=pnLQsCkrZIp0Ax Oycm6VYJ/claqtl0L0VLINqwac3Ja8hpgmit0340fxTrvDNuU+zT86EX+nyMlffOuKi15ApBMDwi1 b8MK6fKu+vOAi2eYhoN1LMC8r67ITydm0gcTn4OpeHQ8pBEC99NU7GYaRp8toSGmd8yWbcBcrkNiW p1aru+zPHoSInJH+RMIl+1II89m5EVPjwwKj4nxgJf0NfILotCPS8MDyD+Q4EfLMnd0Nsi0SpSlyn hkrth6eSKsNThkd9x4AaB1d9xFcxpurbsmsthG6RZrnwPqimLdIvbDsI3lx3ot7sEimtzserbBy+L aFQ1dpocsq6o5vGN3qQg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nh7PU-008VjT-3J; Wed, 20 Apr 2022 10:18:08 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nh7PQ-008ViD-1A for linux-arm-kernel@lists.infradead.org; Wed, 20 Apr 2022 10:18:06 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 67509B81104; Wed, 20 Apr 2022 10:18:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C369EC385A0; Wed, 20 Apr 2022 10:17:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1650449881; bh=lPOiYxN7r9rY59DToiY3IZrya4Qq3lUcsvlK9kSfw7M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=fF9+JRbO0KUKjU8H/en27W2ML8tuYviJJpsxLfDCrl70xc8tW+ltKIHokLR7VvYiI G9vw/s80w5h5TJGwxlQpAuwryxOA1tMA80B960QetlHpHc1choXhjSt8GW9AWUvAo2 Hc8q/VRKAS27tJ9o6bSTfeGupT3cBzRf5+W5OcOCrs3AJBEAKtxylcauJ2f0yHpbnM BbImRa1EppREnj9mh4d7jXQ6F4T9DZE6sFT7/3RaLmQyilgNukUZHvTvEossJqjW9D eOoWtD8bQu04bvMwT72jw1gwyAXvP7KZNWSfIDbL2MVXSGf1Ho0dElmt8gUnow7If4 4zUyvqDOAd0mg== Date: Wed, 20 Apr 2022 11:17:56 +0100 From: Will Deacon To: James Morse Cc: linux-arm-kernel@lists.infradead.org, Russell King , Ard Biesheuvel , Catalin Marinas , Suzuki K Poulose Subject: Re: [PATCH v2 1/2] arm64: errata: Remove AES hwcap for COMPAT tasks Message-ID: <20220420101755.GB7286@willie-the-truck> References: <20220413170545.3042558-1-james.morse@arm.com> <20220413170545.3042558-2-james.morse@arm.com> <20220414100342.GA2298@willie-the-truck> <13a4ce58-b5c6-6715-0e2e-f4aedc6f13fa@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <13a4ce58-b5c6-6715-0e2e-f4aedc6f13fa@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220420_031804_467108_D95BA731 X-CRM114-Status: GOOD ( 33.53 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Thu, Apr 14, 2022 at 06:43:32PM +0100, James Morse wrote: > On 14/04/2022 11:03, Will Deacon wrote: > > On Wed, Apr 13, 2022 at 06:05:44PM +0100, James Morse wrote: > >> Cortex-A57 and Cortex-A72 have an erratum where an interrupt that > >> occurs between a pair of AES instructions in aarch32 mode may corrupt > >> the ELR. The task will subsequently produce the wrong AES result. > >> > >> The AES instructions are part of the cryptographic extensions, which are > >> optional. User-space software will detect the support for these > >> instructions from the hwcaps. If the platform doesn't support these > >> instructions a software implementation should be used. > >> > >> Remove the hwcap bits on affected parts to indicate user-space should > >> not use the AES instructions. > > >> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c > >> index d72c4b4d389c..3faf16f1c040 100644 > >> --- a/arch/arm64/kernel/cpufeature.c > >> +++ b/arch/arm64/kernel/cpufeature.c > >> @@ -1922,6 +1922,12 @@ static void cpu_enable_mte(struct arm64_cpu_capabilities const *cap) > >> } > >> #endif /* CONFIG_ARM64_MTE */ > >> > >> +static void elf_hwcap_fixup(void) > >> +{ > >> + if (cpus_have_const_cap(ARM64_WORKAROUND_1742098)) > >> + compat_elf_hwcap2 &= ~COMPAT_HWCAP2_AES; > >> +} > > > > How does this deal with big/little if we late online an affected CPU? It > > would probably be easier if we treated these CPUs as not having the 32-bit > > AES instructions at all (rather than removing the hwcap later), then the > > early cap check would prevent late onlining. > > I thought any new CPU to online late with a new errata was rejected by the > type == ARM64_CPUCAP_LOCAL_CPU_ERRATUM. Suzuki's documentation in cpufeature.h has: > | However, it is not safe if a "late" CPU requires a workaround and the system hasn't > | enabled it already. > > In this case verify_local_cpu_caps() would take the else for 'system_has_cap', and because > the cpu matches, but ARM64_CPUCAP_LOCAL_CPU_ERRATUM doesn't have the 'late cpu permitted' > bit set, it should call cpu_die_early(). > > That said - I haven't tested this configuration. (I'll give it a go with the model) Ah yes, that probably works, but please do test it to confirm. > v1 did as you suggest - but the HWCAPs are built from the id registers, and touching the > id registers will regress KVM guest migration as the id registers are both visible to > Qemu, and invariant. Hmm, is that really something we expect to work in general? It seems to me that any erratum workaround which effectively removes functionality is going to be a blocker for migration. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel