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=-7.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 9B723C433E0 for ; Thu, 2 Jul 2020 08:20:34 +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 6D69D20720 for ; Thu, 2 Jul 2020 08:20:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="n2mPnNbE"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="VPwnyxWB" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6D69D20720 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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:Message-ID:References:In-Reply-To:Subject:To:From: Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=CfsIt61yjnuoSuTY/G5XIo79anxuJwmLSMDfURfplqE=; b=n2mPnNbEF6mqPmh3KLnhPmmQ2 BVAnh6bvOqquwkxmTOlQ8HWlvFgwZ6TLc9VDtJJKhUWUiwDmZhbiz+eFVA4NQae8BdsNwlg7p/GnD 2wA+7VO27ZSjSYy4z6iVmg1fyHXqh1y229QhBvR3tCVM9kxwCNeZONWjSeRTm6j2KkQlz5W2y8nRG PPmVCD3+G0zG2lXtogc2ylHzEpEDlmRrBToFALLSE2HAk9JKYXtVwL33Q2XzpPb2qLnwZdu3v06km VkyR+8SHXonfcx8+rEcEO6w4AB49uDysBDPIkTfaiYmPP3ieVm2FlvYG8YU50zkiagcRgSQnkX4S9 KpruE9tBA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jquR5-00066B-Tk; Thu, 02 Jul 2020 08:19:12 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jquR2-00063v-6I for linux-arm-kernel@lists.infradead.org; Thu, 02 Jul 2020 08:19:09 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5F86720720; Thu, 2 Jul 2020 08:19:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593677947; bh=lBpbmuDRKPydO8Sg7ZUt/FIHhcGkjT43Ud1CxL0f7/c=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=VPwnyxWBa5DnQmnifLLaD5bNUgXzp69+VvrtNgDO/cEns3VLzaC98CVYVDyoY64f7 fPfW8DRBjJB0ZyTy+yOohKW7ErhaQd9fcB2Vin5w8vu14f0Ds+rSsENymA4+3/MW91 Pm30apL9O3qEccPdZpJEG4qEQetcDr0hY9mziUmk= Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jquQy-008JNL-PM; Thu, 02 Jul 2020 09:19:05 +0100 MIME-Version: 1.0 Date: Thu, 02 Jul 2020 09:19:04 +0100 From: Marc Zyngier To: Will Deacon Subject: Re: Query regarding ERRATUM_1418040 In-Reply-To: <20200701162731.GA15317@willie-the-truck> References: <1ce7dad5-a981-5968-cc34-7648faea8636@codeaurora.org> <062be27686369d28bd2054a54c307400@misterjones.org> <20200617112542.GB3503@willie-the-truck> <20200701162731.GA15317@willie-the-truck> User-Agent: Roundcube Webmail/1.4.5 Message-ID: <4196efaea5fbdf11dd6fa3ba460967d3@kernel.org> X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: will@kernel.org, neeraju@codeaurora.org, linux-arm-kernel@lists.infradead.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200702_041908_400078_FD05474B X-CRM114-Status: GOOD ( 35.03 ) 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: Neeraj Upadhyay , 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 2020-07-01 17:27, Will Deacon wrote: > On Wed, Jun 17, 2020 at 03:29:46PM +0100, Marc Zyngier wrote: >> On 2020-06-17 12:25, Will Deacon wrote: >> > On Wed, Jun 17, 2020 at 12:19:16PM +0100, Marc Zyngier wrote: >> > > On 2020-06-17 09:55, Neeraj Upadhyay wrote: >> > > > I have query regarding the errata 1418040 [1]. Here, on kernel exit to >> > > > EL0 64 bit mode, will it always enable ARCH_TIMER_USR_VCT_ACCESS_EN; >> > > > and override any other erratas, which might require EL0 direct vct >> > > > access to be disabled for 64 bit also? >> > > >> > > So far, I am not aware of any erratum that would require traps of >> > > CNTVCT_EL0 >> > > to EL1 when running AArch64 userspace for CPUs that are affected by >> > > ARM-1418040. If such an erratum exists, it would have to be handled >> > > separately. >> > > >> > > > Also, this errata applies >> > > > mitigation for all CPUs (on return to 32 bit EL0), even if, not all >> > > > cpus are impacted by the errata? >> > > >> > > Indeed. There isn't much we can do to avoid it here, unless you want >> > > to read >> > > some per-CPU variable that tells you whether the CPU is affected. >> > > This would >> > > add to the cost of the mitigation , and isn't an appealing prospect. >> > >> > Hmm, but in conjunction with the previous point, doesn't this mean if >> > some CPUs are affected by an erratum which requires CNTVCT trapping for >> > AArch64 and others are affected by 1418040, then the former won't >> > actually >> > be trapped? >> >> Indeed. Having CPUs that require opposite workarounds is one of the >> many >> fascinating aspects of BL systems... :-/ Does such a system exist >> today? > > I don't know, but it feels like we should either address the issue of > scream > loudly if we detect it! I have no idea how you plan to detect that. >> > Maybe we should preserve ARCH_TIMER_USR_VCT_ACCESS_EN for AArch64 tasks >> > instead of setting it unconditionally? >> >> We'd still need something when switching from an AArch32 task to an >> AArch64 >> one. I guess we'd either need to re-enable it on entry from a 32bit >> task, or >> implement some sort of per-CPU, per-ISA state to be restored on return >> to >> userspace. > > I think re-enabling on entry from a 32-bit task would be the easiest > thing to > do. Since you're playing with 32-bit timer bugs atm, do you fancy > taking a > look ;) I came up with this, tested in a guest only by fudging the detection code (I don't have the offending HW at hand). The use of branches vs NOPs is debatable, no strong opinion here. M. From 81126933d6c990dac7213d0ec66c4a9df21fe8b8 Mon Sep 17 00:00:00 2001 From: Marc Zyngier Date: Wed, 1 Jul 2020 21:29:24 +0100 Subject: [PATCH] arm64: Rework ARM_ERRATUM_1414080 handling The current handling of erratum 1414080 has the side effect that cntkctl_el1 can get changed for both 32 and 64bit tasks. This isn't a problem so far, but if we ever need to mitigate another of these errata on the 64bit side, we'd better keep the messing with cntkctl_el1 local to 32bit tasks. For that, make sure that on entering the kernel from a 32bit tasks, userspace access to cntvct gets enabled, and disabled returning to userspace, while it never gets changed for 64bit tasks. Signed-off-by: Marc Zyngier --- arch/arm64/kernel/entry.S | 44 +++++++++++++++++++++++++-------------- 1 file changed, 28 insertions(+), 16 deletions(-) diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S index 5304d193c79d..357bce62c31e 100644 --- a/arch/arm64/kernel/entry.S +++ b/arch/arm64/kernel/entry.S @@ -167,6 +167,19 @@ alternative_cb_end stp x28, x29, [sp, #16 * 14] .if \el == 0 + .if \regsize == 32 + // If we come back from a 32bit task on a system affected by + // 1418040, let's reenable userspace access to the virtual counter. +#ifdef CONFIG_ARM64_ERRATUM_1418040 +alternative_if_not ARM64_WORKAROUND_1418040 + b .L__entry_wa_1418040\@ +alternative_else_nop_endif + mrs x0, cntkctl_el1 + orr x0, x0, #2 // ARCH_TIMER_USR_VCT_ACCESS_EN + msr cntkctl_el1, x0 +.L__entry_wa_1418040\@: +#endif + .endif clear_gp_regs mrs x21, sp_el0 ldr_this_cpu tsk, __entry_task, x20 @@ -318,7 +331,21 @@ alternative_else_nop_endif ldr x23, [sp, #S_SP] // load return stack pointer msr sp_el0, x23 tst x22, #PSR_MODE32_BIT // native task? - b.eq 3f + b.eq 4f + +#ifdef CONFIG_ARM64_ERRATUM_1418040 +alternative_if_not ARM64_WORKAROUND_1418040 + b 3f +alternative_else_nop_endif + /* + * if (x22.mode32 == 1) + * cntkctl_el1.el0vcten = 0 + */ + mrs x1, cntkctl_el1 + bfi x1, xzr, #1, #1 // ARCH_TIMER_USR_VCT_ACCESS_EN + msr cntkctl_el1, x1 +3: +#endif #ifdef CONFIG_ARM64_ERRATUM_845719 alternative_if ARM64_WORKAROUND_845719 @@ -330,22 +357,7 @@ alternative_if ARM64_WORKAROUND_845719 #endif alternative_else_nop_endif #endif -3: -#ifdef CONFIG_ARM64_ERRATUM_1418040 -alternative_if_not ARM64_WORKAROUND_1418040 - b 4f -alternative_else_nop_endif - /* - * if (x22.mode32 == cntkctl_el1.el0vcten) - * cntkctl_el1.el0vcten = ~cntkctl_el1.el0vcten - */ - mrs x1, cntkctl_el1 - eon x0, x1, x22, lsr #3 - tbz x0, #1, 4f - eor x1, x1, #2 // ARCH_TIMER_USR_VCT_ACCESS_EN - msr cntkctl_el1, x1 4: -#endif scs_save tsk, x0 /* No kernel C function calls after this as user keys are set. */ -- 2.27.0 -- Jazz is not dead. It just smells funny... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel