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 6D57CC04A95 for ; Tue, 25 Oct 2022 05:09:46 +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=bAXX3pD4aI+cu5e83cRa+58IvkRx+74HvFUqt3/z+YY=; b=I7PGlMdz3Cb5f6 7Kwkv1rvF22BEwm2PSHov/bDxktpqh4dQwrzrAi/4q/4sjpVk89pD1GCKzsTva2+O5CwSSJ36Dzlq /y/BYLVAW3CZKsxtCl24bQv8cwVMxfeNiZpiSwt7Bs9Agyz/vlCiGI49iPwyV7Ti1aYbD7AhPEfrZ r9NsyYjvQ9i518m7RsBPSHLcz8StV/TqqI8gHtRXi6T/OCybnlVE/JxJWRxjzsS/Xlx3LVDQNgZbI DE8Kvf/8l5en/L/4JYL4BvqVolk49ZgrDVNQAJGTY9FbZML1PDGok0VqcszYuDPtMtt9asjRi+hvH /BIAAhVBPF+0nhIt0YqQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1onCB3-003rv0-KA; Tue, 25 Oct 2022 05:08:37 +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 1onC9Q-003rI1-3v for linux-arm-kernel@lists.infradead.org; Tue, 25 Oct 2022 05:06:58 +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 2DFC1B81A76; Tue, 25 Oct 2022 05:06:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 91FD0C433D7; Tue, 25 Oct 2022 05:06:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1666674412; bh=PhAvkA+YfdXpkTGuM4QF1TubeX/M39i3zMfp0nDwnNI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=gdzVXZnDZXkvLcl2UrckpkcK20KG0qUGhbBB3VlMtrQerDXWv1t8ywEzJANQEfpN8 64p3rplQZqwKexR8wnQfuMIkjLkrlg6couk7pIBthi11VCYMx5eouCFO5qotQRDxIP r6fSjbaBtj2lGdUOxlJGDEcj6FqjdvpJtZ0AxE9Od52wGi4tdIK4OBcXcq3NNCng+M mm+t6L0dyb3SyRVsCicJq/cd4M24LOCdpl4Mn6tDRnQHAMA9uiGsFdYOXV6lRXx1xc yN6wH5ZU5PHgiUS24KiwjjrlQ7hXNnKt+Fdyhg7Dj/5FDQ21Bf7QA+dPIdd/xUPjgV V3jWt1ggvUS4Q== Date: Mon, 24 Oct 2022 22:06:50 -0700 From: Eric Biggers To: Peter Zijlstra Cc: Dave Hansen , "Jason A. Donenfeld" , x86@kernel.org, linux-arm-kernel@lists.infradead.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, Adam Langley , Ard Biesheuvel Subject: Re: Should Linux set the new constant-time mode CPU flags? Message-ID: References: <6ec9cdab-db5b-ab28-c92d-79c3812dd369@intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221024_220656_489736_B08D7066 X-CRM114-Status: GOOD ( 28.74 ) 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, Sep 01, 2022 at 01:00:29PM +0200, Peter Zijlstra wrote: > Since I'm not feeling too well I figured I'd do something trivial and > whipped up the below patch. > > > --- > arch/x86/include/asm/cpufeatures.h | 3 ++ > arch/x86/include/asm/msr-index.h | 4 +++ > arch/x86/kernel/cpu/common.c | 69 ++++++++++++++++++++++++++++++-------- > arch/x86/kernel/cpu/scattered.c | 1 + > 4 files changed, 63 insertions(+), 14 deletions(-) We still need to do something about this. As this thread died out, I'll revive it by reviewing this patch. (I'm not an expert in arch/x86/ stuff, though!) > diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h > index 333d94394516..9b92f4e5e80a 100644 > --- a/arch/x86/include/asm/cpufeatures.h > +++ b/arch/x86/include/asm/cpufeatures.h > @@ -305,6 +305,7 @@ > #define X86_FEATURE_USE_IBPB_FW (11*32+16) /* "" Use IBPB during runtime firmware calls */ > #define X86_FEATURE_RSB_VMEXIT_LITE (11*32+17) /* "" Fill RSB on VM exit when EIBRS is enabled */ > #define X86_FEATURE_CALL_DEPTH (11*32+18) /* "" Call depth tracking for RSB stuffing */ > +#define X86_FEATURE_MCDT_NO (11*32+19) /* Not affected by MCDT */ Some of the other CPU feature flags have comments beginning with "", which apparently results in the feature not being listed in /proc/cpuinfo. (This header file is run through a shell script that looks at these comments and generates C code...) Should this "feature" be listed in /proc/cpuinfo? Looking for examples of other "feature" flags that mean that a CPU is not vulnerable to something, I found X86_FEATURE_AMD_SSB_NO and X86_FEATURE_BTC_NO. Those aren't listed in /proc/cpuinfo. Maybe this should be the same? Side note: maybe the comment should spell out "MXCSR Configuration Dependent Timing"? Acronyms can be hard to read. > +#define X86_BUG_DOIT X86_BUG(28) Maybe it should be X86_BUG_DODT? The bug is data operand *dependent* timing. Data operand *independent* timing is the desired behavior and the fix. > +#define X86_BUG_MCDT X86_BUG(29) According to Intel's documentation (https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/data-operand-independent-timing-isa-guidance.html), MCDT is a separate bug which requires a separate mitigation. So I think any MCDT related stuff should be in a separate patch from DOITM. But more importantly, this patch doesn't actually implement any mitigation for MCDT. Should we be doing that? Intel recommends writing a certain value to MXCSR to mitigate MCDT. Is that feasible? > > #endif /* _ASM_X86_CPUFEATURES_H */ > diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h > index 6674bdb096f3..08b4e0c2f7d3 100644 > --- a/arch/x86/include/asm/msr-index.h > +++ b/arch/x86/include/asm/msr-index.h > @@ -119,6 +119,7 @@ > * Not susceptible to > * TSX Async Abort (TAA) vulnerabilities. > */ > +#define ARCH_CAP_DOIT BIT(12) /* Data Operand Independent Timing */ > #define ARCH_CAP_SBDR_SSDP_NO BIT(13) /* > * Not susceptible to SBDR and SSDP > * variants of Processor MMIO stale data > @@ -155,6 +156,9 @@ > * Return Stack Buffer Predictions. > */ > > +#define MSR_IA32_UARCH_MISC_CTL 0x00001b01 > +#define UARCH_MISC_DOIT BIT(0) /* Enable DOIT */ The Intel documentation calls this bit "DOITM" (Data Operand Independent Timing Mode), not "DOIT". > +static __always_inline void setup_doit(struct cpuinfo_x86 *c) > +{ > + u64 msr = 0; > + > + if (!cpu_has(c, X86_BUG_DOIT)) > + return; > + > + if (!doit_disabled) > + return; This is backwards; it needs to be 'if (doit_disabled)'. > diff --git a/arch/x86/kernel/cpu/scattered.c b/arch/x86/kernel/cpu/scattered.c > index fd44b54c90d5..5063f8046554 100644 > --- a/arch/x86/kernel/cpu/scattered.c > +++ b/arch/x86/kernel/cpu/scattered.c > @@ -27,6 +27,7 @@ static const struct cpuid_bit cpuid_bits[] = { > { X86_FEATURE_APERFMPERF, CPUID_ECX, 0, 0x00000006, 0 }, > { X86_FEATURE_EPB, CPUID_ECX, 3, 0x00000006, 0 }, > { X86_FEATURE_INTEL_PPIN, CPUID_EBX, 0, 0x00000007, 1 }, > + { X86_FEATURE_MCDT_NO, CPUID_ECX, 5, 0x00000007, 2 }, The Intel documentation says this bit is CPUID.(EAX=7H,ECX=2):EDX[5]=1. So CPUID_ECX is wrong; it needs to be CPUID_EDX. - Eric _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel