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 7F4C6C433F5 for ; Mon, 20 Dec 2021 16:42:27 +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:MIME-Version:Message-ID:Date:References :In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=jS3l67uvCa1gUaCPf+N0jcvpg3EjHPQY+RRrXzk/BHg=; b=dmbtT5BSdDZM1K /mKVdhRfxSyzxN7Ti4u/QHZJFu/fRCgcWhPdT1bHEZzEcDSlk9y1yzswQuHtZQ8+ADiPxQlpPRXSX rjXrPIMnwIgSymyE4bl+6N5NLAHWPgxtRnyJ6MOmMo1HACLf1TuVPan9izlMZFPy6Izn4kf+msuX+ 1x1vXDxguABX2dE3PnVYpGT9Hp0zaJWp5JQmnCtyal+jPiK1g9Hqr61d3fWScTEL3U0M6jmDznzt/ LINFVgrf8U5IpIQ1y+28Ni03lv60sChYark8URE/XbIfgh9vwEW95j3NSl2dp3iWz4VhB4UAZU3Tb v6StsUJB8J8k+PN+XKcw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mzLid-003L98-Vg; Mon, 20 Dec 2021 16:41:00 +0000 Received: from mail-dm6nam12on2104.outbound.protection.outlook.com ([40.107.243.104] helo=NAM12-DM6-obe.outbound.protection.outlook.com) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mzLiZ-003L7T-MC for linux-arm-kernel@lists.infradead.org; Mon, 20 Dec 2021 16:40:57 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jrfMupgfbIL5VFWczto/YfHM6xlRef4+TXbN+TVjEqIpP7Fx5lJyFxLdlycqeWHa9L+hq0TmOB6P+mQXD70eFVsYJFMqM0/U3NKGVw7M8W2BNfk+yeWjTtgR2KeJ1R7Jd9xsMeH2ukcYkN/0eMOZS6K2buVXq/um8jGGhMlE0ba59fKYZwr27Z7K1gCkwReGE3CbfNKDXh5jTWAtnigGObrBZP3JvdzuwsSvvFyB7sXUFQuSL3z88a2uK6MZZglowx83NlKOOptMEJWNV4HyTYZ9DWuwaHMcUfFtgEHXGNawf4RGNpkjp2pEDzlevy8Fo2Wr01omj8CTlyauB//1Vw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SSnvDyLAQBsGMXV/P2lyW+l45Y26ncmOoM+2Y9kSh7M=; b=FEWhqxvStkxlu1ttsvukyIh+N94lRzu2FIRyc5JagsOUBAW45b5X+ow42c+ITvZ6W2757JzsKXmK8qK+Ie3zg2WrTxjsqqab8VmUAn3hAUR8OLPCuzIRGxQuIfnN5g8hCjVs53oHI0PxPXOLFAijUw2Za3eTZr0seGt9QMEEwwJziGMQ2FCFBwZgFdGWA2nS64T8kCgNDr75agodMuwDGs1lijkFB2Nzn3OEygBwHJe1WMoIuPcvw9SPrGXx6OEXe04nnjpbdXNTcrP1P5txHsQaCvsUj+aQnZeTrvXWrT8Jztn5an/Icmy9Zu4J1BhCpuCdylCIZOSfPxFSAS/I3g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=os.amperecomputing.com; dmarc=pass action=none header.from=os.amperecomputing.com; dkim=pass header.d=os.amperecomputing.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=os.amperecomputing.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SSnvDyLAQBsGMXV/P2lyW+l45Y26ncmOoM+2Y9kSh7M=; b=HAgobVNk9yqWWqvLNyiCdnXUf8gKx5GgW+f7yHSx6knAa//uSaqAqCM+sUiArq4ngQQFWPShKVuRIwyIutc4UiK+cV4F8npJkHDVn/xWLR5f3cznJZpmCL9AolcNQmQ55S+7uwKY5yQ7eErc+ASNWlWwuJT5xXQMEbuEDIBqhdg= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=os.amperecomputing.com; Received: from MWHPR0101MB2893.prod.exchangelabs.com (2603:10b6:301:33::25) by MWHPR01MB2415.prod.exchangelabs.com (2603:10b6:300:3f::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4801.20; Mon, 20 Dec 2021 16:40:49 +0000 Received: from MWHPR0101MB2893.prod.exchangelabs.com ([fe80::526:8374:e93f:3648]) by MWHPR0101MB2893.prod.exchangelabs.com ([fe80::526:8374:e93f:3648%4]) with mapi id 15.20.4801.020; Mon, 20 Dec 2021 16:40:49 +0000 From: D Scott Phillips To: Marc Zyngier Cc: linux-arm-kernel@lists.infradead.org, Catalin Marinas , Will Deacon , Darren Hart , patches@amperecomputing.com Subject: Re: [PATCH v4] arm64: errata: Fix exec handling in erratum 1418040 workaround In-Reply-To: <87ee67wkj4.wl-maz@kernel.org> References: <20211217211920.2004032-1-scott@os.amperecomputing.com> <87ee67wkj4.wl-maz@kernel.org> Date: Mon, 20 Dec 2021 08:40:45 -0800 Message-ID: <8635mngrg2.fsf@scott-ph-mail.amperecomputing.com> X-ClientProxiedBy: CH2PR11CA0010.namprd11.prod.outlook.com (2603:10b6:610:54::20) To MWHPR0101MB2893.prod.exchangelabs.com (2603:10b6:301:33::25) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b2e2431c-58f2-4f90-af61-08d9c3d77a84 X-MS-TrafficTypeDiagnostic: MWHPR01MB2415:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6790; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: LalcXB/VwGscunG4esP6jgJ3B0YztD6R4m7vtNS54erEx2qA3GCt/5jAi0LOPGZkFCtgMn5VMp3kuWo9eqMBLycinmAR5xydFd8XaGtuwOK0i2KpKvRDAx7WuBWfxNRS/PZ9/V97jRz5jfkpAVfqHNOD7jiIfCSgp7BwDn+ryCAmEX4UGGYXZjFKsV3gb792ZRzSmBtypsZwnlq4D5MC2xN8mAtB/M1UBocbk5Ag2Ih2v+rV1kSdqXtpPqKFA964a9NgAvjIMOhQls0K1RU5kMxBDuaaSmTnmbbgjmpD4DzcdOzqGED13Il3rXCGQbXnwq3KT1k2+uYYlMy6mgr5uvi/BtkrpxqpoWCbks6ru2f3jwUittETPd/mdQC/beeDvGE3jgnu7Pk6J7njYo9CsI0pNjihorPyzFOSwXasALObiksHUUkiXRGsXLwNlnTnCLFx/o2rbSMEffGDTkasUzymTgKg0guSwqgJ/LzCC0zcStSwX3ZONNdVrtwKX0vLlqUoTA66FKu2PcClpcnd8cnmKGgYA02hgvXe3l1d3V1hiEqnqNPLZRf5V0Ifj6QDPs6Q81y8COOq6zgC+6Do000fBsdisFHOD33RAl8MMDKqkdkZysi8pE1Gy1RLxSqodJdp+gT4tHNGB0UWCZ5gA6sOOenTyMNau6wrNcZ8MQQb3RAfqqnD3G13dd97YCqgv9TzJ84H292Dq/LIve44LA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR0101MB2893.prod.exchangelabs.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(9686003)(8936002)(38100700002)(2906002)(508600001)(6486002)(38350700002)(52116002)(107886003)(6512007)(6916009)(26005)(316002)(8676002)(86362001)(83380400001)(54906003)(186003)(6506007)(5660300002)(4326008)(66946007)(6666004)(66476007)(66556008); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?OdXKBHJcVKcsR4Vp41Ix/NhW0QQwe/q/KIeiHyAxlqn4QBhSAT8eZ/v74AXu?= =?us-ascii?Q?NHjW4vRcLa0WCUIul2JtsDEQNJ8VwRRlJeoa4YACI3QrUMV/5TI2Ucg5Jc9r?= =?us-ascii?Q?X3D14GQbdxSODfnqcVWsXNkx0gYszl5G4KergUFBXMZd1HucwWLtV9K6A5ov?= =?us-ascii?Q?oTep6mIt+SMN6nn7/MHftjmaOu5By0hZvyniB8sfifkWdOF3Twj0PjK0FfzL?= =?us-ascii?Q?ZgVjyPus+WqEeSnEqd9bEiF2DmOt2lxXjmb3CC2ctwSyaovUr1VdihiBJYTg?= =?us-ascii?Q?CI0PIjmtYDEeO9ufBipbLUt8/XUlEsmOsaGSZfZ+LDX0uLwglsTY4H5SUsGx?= =?us-ascii?Q?x9+2/Pdi5/A5JPWOvqdhiznrdCzwHfXoYNccI7Zh/9R6mHabj3XGh2jrCH8p?= =?us-ascii?Q?Tk4zL8fjFuXTjrHeQ/TG3bQoGtswNibEsCP7HA9wdB5Ue/DI/N5yjuR65xEa?= =?us-ascii?Q?3HWka+x02y3rDDW2MuccUQkbo5oYQ2TwXr6XFSbzciE/NSI6ZqXapDm+6FKd?= =?us-ascii?Q?GOmWpUZeLJcKu4S4Zq/WV0YGqxTqi1Wh20Km1AAZSCzPFbk6f1/7kvzdZ2cv?= =?us-ascii?Q?BGkhsNT/dul6SYRi6NOgG3nOXbvigQb0oSqLlPjiXgzmKCseNU7cnDLe52s7?= =?us-ascii?Q?5aQE55EdM+oZ2pJwbl53euU/3TCQdWxqk6BXK8HVWPXEK0PGL0N831XPvWE+?= =?us-ascii?Q?bdvxU8dmlg+QxRYAUEqIavfxEUYeDhNYvamXJGlqp1GBseEdoufyugJt77Jt?= =?us-ascii?Q?4ZfRFtsdFj3Cp85pIf3ko6gE2VfcZ4u1rYojZ5rNqK5POkYsJ4XgTqs2Gl6C?= =?us-ascii?Q?zOtuLzdpkY8Rk0IfOb1G+6KfCH1ppSjekLLgzmMhIMGGl3sPEaSUGZtgi3fB?= =?us-ascii?Q?IQvGyVM1lA5C6TMFmkymMMuFxrueZ3Ywe2wqtAMhKOEycSA/jffmQXgIIwM9?= =?us-ascii?Q?2FCGkdE2DAoth3rsEt97xm9OrP246nw/OtsUojXsRznmknFOv+ln6J4tQrd/?= =?us-ascii?Q?qXq4LHd2jtv5ThBLZKY834CngaEAUXukJgpUqTBq3sf7HGQGmlMWNjj41Zrw?= =?us-ascii?Q?5yHPix493N86rShWbI2Ft9Bz8RpGygEucHiK3MH0xIWoblkRfw9+6HYigDpI?= =?us-ascii?Q?JfPUMzsOs+RsMEBc+wd+2SaUWxJOQfenIT0px+0Uu843wici/HlmHyh9ueND?= =?us-ascii?Q?ODf2WRCN+0yj2YWQqDDPZb2FX7tJwIAeYVNs3OG2TjFNWJW+90KxXF06IBSS?= =?us-ascii?Q?QwsjFtonpqfcq1w0QOuzzei1aCAqUeMF3mFHD61nKdO3JazYgrmgO+RQHv1d?= =?us-ascii?Q?nHDQNqeaBAkOpQp5I71LyJ+gKRNHprm28KkHBzitlbEyPcQ5EOfLU9bAA9ME?= =?us-ascii?Q?5jtgI1ofg5vmzIM46YPYQXW/xSyyd3lz4lbXKee12D7o69RHLXA9QCcSg6u0?= =?us-ascii?Q?RzOz+1gG8iD/Ozd0cr8FKOyuPoDy6bvXJ1+SBcro2/g53pLbagx38IsPn8TS?= =?us-ascii?Q?w/yBP1FxfkGAgDkQuID53IvvTuTn5NhWYPcsXS6El7RGj1GKU1/d3n7FfeKQ?= =?us-ascii?Q?Jco1GHSX4isYqWRZc1wiv837GDKlecJ7jIza33x/9I+Fu1jdHA9h6mqhxKR6?= =?us-ascii?Q?0hon3gsuOVJy3o+5cSHg6a5wcl/syKTqSg35B2+Olm2jHF37VMDXuqpLRHb7?= =?us-ascii?Q?6T4COR997c1VVhS4/03b+Sr42ZkCZRWKyS6tnpzALaGZrHCH6fz9TVgiwUKT?= =?us-ascii?Q?PHecvAkDVg=3D=3D?= X-OriginatorOrg: os.amperecomputing.com X-MS-Exchange-CrossTenant-Network-Message-Id: b2e2431c-58f2-4f90-af61-08d9c3d77a84 X-MS-Exchange-CrossTenant-AuthSource: MWHPR0101MB2893.prod.exchangelabs.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Dec 2021 16:40:49.4599 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3bc2b170-fd94-476d-b0ce-4229bdc904a7 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Yy7BzFoTtMX7f9FEa6nwB4MEtXys7+MO2gGvwJYWB+slFkO9vSvCuwV3pqqyUvHX/reuCx+ZxEgMCZAQ1pwB44qZS/vJM4LaRidz5Yfbb6H1k+f3KBDBL+Fg39r59Vuq X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR01MB2415 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211220_084055_829004_3A1AF426 X-CRM114-Status: GOOD ( 29.14 ) 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 Marc Zyngier writes: > On Fri, 17 Dec 2021 21:19:20 +0000, > D Scott Phillips wrote: >> >> The erratum 1418040 workaround enables vct access trapping when executing > > nit: s/vct/CNTVCT_EL1/. fixed, thanks >> compat threads. The workaround is applied when switching between tasks, but >> the need for the workaround could also change at an exec(), when a >> non-compat task execs a compat binary or vice versa. Apply the workaround >> in arch_setup_new_exec(). >> >> The leaves a small window of time between SET_PERSONALITY and >> arch_setup_new_exec where preemption could occur and confuse the old >> workaround logic that compares TIF_32BIT between prev and next. Instead, we >> can just read cntkctl to make sure it's in the state that the next task >> needs. I measured cntkctl read time to be about the same as a mov from a >> general-purpose register on N1. Update the workaround logic to examine the >> current value of cntkctl instead of the previous task's compat state. >> >> Fixes: d49f7d7376d0 ("arm64: Move handling of erratum 1418040 into C code") >> Signed-off-by: D Scott Phillips >> Cc: # 5.4.x >> --- >> >> v4: - Move exec() handling into arch_setup_new_exec(), drop prev32==next32 >> comparison to fix possible confusion in the small window between >> SET_PERSONALITY() and arch_setup_new_exec(). (Catalin) >> >> v3: - Un-nest conditionals (Marc) >> >> v2: - Use sysreg_clear_set instead of open coding (Marc) >> - guard this_cpu_has_cap() check under IS_ENABLED() to avoid tons of >> WARN_ON(preemptible()) when built with !CONFIG_ARM64_ERRATUM_1418040 >> >> arch/arm64/kernel/process.c | 34 ++++++++++++---------------------- >> 1 file changed, 12 insertions(+), 22 deletions(-) >> >> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c >> index aacf2f5559a8..b37ff23e625e 100644 >> --- a/arch/arm64/kernel/process.c >> +++ b/arch/arm64/kernel/process.c >> @@ -439,34 +439,23 @@ static void entry_task_switch(struct task_struct *next) >> >> /* >> * ARM erratum 1418040 handling, affecting the 32bit view of CNTVCT. >> - * Assuming the virtual counter is enabled at the beginning of times: >> - * >> - * - disable access when switching from a 64bit task to a 32bit task >> - * - enable access when switching from a 32bit task to a 64bit task >> + * Ensure access is disabled when switching to a 32bit task, ensure >> + * access is enabled when switching to a 64bit task. >> */ >> -static void erratum_1418040_thread_switch(struct task_struct *prev, >> - struct task_struct *next) >> +static void erratum_1418040_thread_switch(struct task_struct *next) >> { >> - bool prev32, next32; >> - u64 val; >> - >> - if (!IS_ENABLED(CONFIG_ARM64_ERRATUM_1418040)) >> - return; >> + preempt_disable(); > > I'd rather avoid this on the __switch_to() path. We're guaranteed to > be non-preemptible when called from there, and we want it to be as > fast as possible. It would also avoid the bug on the early return just > below. Yes, makes sense. I've added an erratum_1418040_new_exec() helper that does preempt_disable/erratum_14518040_thread_switch(current)/preempt_enable, and called it from arch_setup_new_exec(). >> >> - prev32 = is_compat_thread(task_thread_info(prev)); >> - next32 = is_compat_thread(task_thread_info(next)); >> - >> - if (prev32 == next32 || !this_cpu_has_cap(ARM64_WORKAROUND_1418040)) >> + if (!IS_ENABLED(CONFIG_ARM64_ERRATUM_1418040) || >> + !this_cpu_has_cap(ARM64_WORKAROUND_1418040)) >> return; >> >> - val = read_sysreg(cntkctl_el1); >> - >> - if (!next32) >> - val |= ARCH_TIMER_USR_VCT_ACCESS_EN; >> + if (is_compat_thread(task_thread_info(next))) >> + sysreg_clear_set(cntkctl_el1, ARCH_TIMER_USR_VCT_ACCESS_EN, 0); >> else >> - val &= ~ARCH_TIMER_USR_VCT_ACCESS_EN; >> + sysreg_clear_set(cntkctl_el1, 0, ARCH_TIMER_USR_VCT_ACCESS_EN); >> >> - write_sysreg(val, cntkctl_el1); >> + preempt_enable(); >> } >> >> /* >> @@ -501,7 +490,7 @@ __notrace_funcgraph struct task_struct *__switch_to(struct task_struct *prev, >> contextidr_thread_switch(next); >> entry_task_switch(next); >> ssbs_thread_switch(next); >> - erratum_1418040_thread_switch(prev, next); >> + erratum_1418040_thread_switch(next); >> ptrauth_thread_switch_user(next); >> >> /* >> @@ -611,6 +600,7 @@ void arch_setup_new_exec(void) >> current->mm->context.flags = mmflags; >> ptrauth_thread_init_user(); >> mte_thread_init_user(); >> + erratum_1418040_thread_switch(current); > > But what is the point of this now? As you enter __switch_to(), the TIF > flags are set in stone for this particular return to userspace. > > Since you are now evaluating the state of CNTKCTL_EL1 on each and > every switch, you are guaranteed to set the enable bit to the right > value on each return to userspace, even if you have gone via > SET_PERSONALITY(). > > Am I missing something? The workaround in __switch_to isn't happening for every return to userspace, but rather for every scheduler task switch. When a process exec()s, no switch happens at that point. From the scheduler point of view, this is still the same task. So in the time period between exec()ing a compat task from non-compat (or vice versa) and the first time it gets switched out, we would apply the wrong workaround state, unless we make a change to cntkctl from exec() before returning back to EL0. Thanks, Scott _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel