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 126E9C433EF for ; Thu, 14 Jul 2022 16:06:51 +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:Date: Message-ID:From:References:Cc:To:Subject:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=GVpGd+OTdYqma48N1Q5A993T/9dnvNVdL9NqRbSlY8Y=; b=1UwKN9ky7ZNzY8xKwFxWGaP1Pk EDIyapSL+RCELPeKDDoIK7VSNcyK/Gzihrd0sv+3/fmDHnDKzIgkTu25X9bB8nVKkWxiq2cwgKVtl 9e5cI/izArth7PiMDmCfCbjsZgSb4CsQch3nMc/W8I4Kqf7UCULFDXfb55ffCJery4kKdaX0n+ZWL nui4N7OkHVZaERHo0NkbybmiJWT31RdIsiFgG4Aq0OMJpHevCK02iogop5sGtO/aYV99/GENmPT7D XEp62H9sGvgCVtUe9j0nnWcaN01zY3QvH2RGq7tC4d2uB+ec2nwUUaHqR212XEwSRFE/eSNfUgE1Z C0FvmNUA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oC1LM-00G3mS-1I; Thu, 14 Jul 2022 16:05:36 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oC1LG-00G3e8-71 for linux-arm-kernel@lists.infradead.org; Thu, 14 Jul 2022 16:05:32 +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 357861D14; Thu, 14 Jul 2022 09:05:25 -0700 (PDT) Received: from [10.1.196.174] (eglon.cambridge.arm.com [10.1.196.174]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id ED2173F70D; Thu, 14 Jul 2022 09:05:23 -0700 (PDT) Subject: Re: [PATCH v2 1/2] arm64: errata: Remove AES hwcap for COMPAT tasks To: Will Deacon Cc: linux-arm-kernel@lists.infradead.org, Russell King , Ard Biesheuvel , Catalin Marinas , Suzuki K Poulose 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> <20220420101755.GB7286@willie-the-truck> From: James Morse Message-ID: <0e5ba81b-62cd-1a5e-d810-faa0cad1f810@arm.com> Date: Thu, 14 Jul 2022 17:05:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20220420101755.GB7286@willie-the-truck> Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220714_090530_400191_4972DAB1 X-CRM114-Status: GOOD ( 26.07 ) 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 Hi Will, On 20/04/2022 11:17, Will Deacon wrote: > 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. The workaround is only for the host. The guest may already have the workaround. I think these things should be kept separate unless the guest would be broken by the workaround. We don't normally apply workaround for EL1 from EL2 unless its needed by the host. Its up to the guest to have its own workaround. Thanks, James _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel