From nobody Mon Apr 27 10:04:57 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5DA15CCA47A for ; Tue, 14 Jun 2022 18:43:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357282AbiFNSm7 (ORCPT ); Tue, 14 Jun 2022 14:42:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58118 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357117AbiFNSmY (ORCPT ); Tue, 14 Jun 2022 14:42:24 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AB91C49F98; Tue, 14 Jun 2022 11:41:55 -0700 (PDT) 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 dfw.source.kernel.org (Postfix) with ESMTPS id 1799E617C1; Tue, 14 Jun 2022 18:41:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 206CBC3411B; Tue, 14 Jun 2022 18:41:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1655232114; bh=8aDocrP+cvwVW9n5ue1laKbh2vms4K1+DDLPSRmNg40=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=d0DX2MxnVzoRymhSBqTJgs/WM9YudpXHLXzR31PgcloknGaExUBD0hESPzPxPrd88 tU2FN34DshFfTHynRQUYO9vPnQQgNPV9fVQTLwCwQdJszROe/NYsG12XfiH7K/+Ad5 sX9BqvRJtvtSPOR+QS36G4KknjFmiO1jhxcLXxxs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Gayatri Kammela , Tony Luck , Linus Torvalds , Peter Zijlstra , Rahul Tanwar , Thomas Gleixner , Ingo Molnar , Thadeu Lima de Souza Cascardo Subject: [PATCH 4.9 01/20] x86/cpu: Add Elkhart Lake to Intel family Date: Tue, 14 Jun 2022 20:39:44 +0200 Message-Id: <20220614183722.422168868@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220614183722.061550591@linuxfoundation.org> References: <20220614183722.061550591@linuxfoundation.org> User-Agent: quilt/0.66 X-stable: review X-Patchwork-Hint: ignore MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Gayatri Kammela commit 0f65605a8d744b3a205d0a2cd8f20707e31fc023 upstream. Add the model number/CPUID of atom based Elkhart Lake to the Intel family. Signed-off-by: Gayatri Kammela Signed-off-by: Tony Luck Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Rahul Tanwar Cc: Thomas Gleixner Link: https://lkml.kernel.org/r/20190905193020.14707-3-tony.luck@intel.com Signed-off-by: Ingo Molnar Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/x86/include/asm/intel-family.h | 2 ++ 1 file changed, 2 insertions(+) --- a/arch/x86/include/asm/intel-family.h +++ b/arch/x86/include/asm/intel-family.h @@ -67,7 +67,9 @@ #define INTEL_FAM6_ATOM_GOLDMONT 0x5C /* Apollo Lake */ #define INTEL_FAM6_ATOM_GOLDMONT_X 0x5F /* Denverton */ #define INTEL_FAM6_ATOM_GOLDMONT_PLUS 0x7A /* Gemini Lake */ + #define INTEL_FAM6_ATOM_TREMONT_X 0x86 /* Jacobsville */ +#define INTEL_FAM6_ATOM_TREMONT 0x96 /* Elkhart Lake */ =20 /* Xeon Phi */ From nobody Mon Apr 27 10:04:57 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A47D1C43334 for ; Tue, 14 Jun 2022 18:41:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345354AbiFNSlJ (ORCPT ); Tue, 14 Jun 2022 14:41:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57800 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344780AbiFNSlC (ORCPT ); Tue, 14 Jun 2022 14:41:02 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ECAAB48E65; Tue, 14 Jun 2022 11:41:01 -0700 (PDT) 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 dfw.source.kernel.org (Postfix) with ESMTPS id 87C0C617BA; Tue, 14 Jun 2022 18:41:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 948EFC3411B; Tue, 14 Jun 2022 18:41:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1655232060; bh=/toawXixZnJbTpKsGyjEpXL+h5RveDfzDka39oMDCUQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qrgQ/Kk4LJe4dkxQsU43QOgf6j0VGlPSgOIoiMp2UuPm5VPX5/eyPRSErN70hzOfP 8O7rdJQkf043Qu17615v7at37q3QeA3W9Xsooh8pmaGcACTLmVRVkg4xac0QTDR1wU G1jp/KzXRzeiZ/HdaJ0K+7mOAAvgZcZgZubjHIb0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, kernel test robot , Guenter Roeck , Borislav Petkov , Thomas Gleixner , Thadeu Lima de Souza Cascardo Subject: [PATCH 4.9 02/20] cpu/speculation: Add prototype for cpu_show_srbds() Date: Tue, 14 Jun 2022 20:39:45 +0200 Message-Id: <20220614183722.671286042@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220614183722.061550591@linuxfoundation.org> References: <20220614183722.061550591@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Guenter Roeck commit 2accfa69050c2a0d6fc6106f609208b3e9622b26 upstream. 0-day is not happy that there is no prototype for cpu_show_srbds(): drivers/base/cpu.c:565:16: error: no previous prototype for 'cpu_show_srbds' Fixes: 7e5b3c267d25 ("x86/speculation: Add Special Register Buffer Data Sam= pling (SRBDS) mitigation") Reported-by: kernel test robot Signed-off-by: Guenter Roeck Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/20200617141410.93338-1-linux@roeck-us.net Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- include/linux/cpu.h | 1 + 1 file changed, 1 insertion(+) --- a/include/linux/cpu.h +++ b/include/linux/cpu.h @@ -61,6 +61,7 @@ extern ssize_t cpu_show_tsx_async_abort( char *buf); extern ssize_t cpu_show_itlb_multihit(struct device *dev, struct device_attribute *attr, char *buf); +extern ssize_t cpu_show_srbds(struct device *dev, struct device_attribute = *attr, char *buf); =20 extern __printf(4, 5) struct device *cpu_device_create(struct device *parent, void *drvdata, From nobody Mon Apr 27 10:04:57 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BCAC2CCA47B for ; Tue, 14 Jun 2022 18:42:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357091AbiFNSmR (ORCPT ); Tue, 14 Jun 2022 14:42:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58174 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347374AbiFNSls (ORCPT ); Tue, 14 Jun 2022 14:41:48 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6D1594A918; Tue, 14 Jun 2022 11:41:33 -0700 (PDT) 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 dfw.source.kernel.org (Postfix) with ESMTPS id BFC5C617C1; Tue, 14 Jun 2022 18:41:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE2E2C3411B; Tue, 14 Jun 2022 18:41:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1655232092; bh=Ji1Sndb5sEdNz4okiXUxRbPTXMSEoXeX0mSgQzcisgw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DmbrkLo6w0Fea3Urt10aRt3tVS2qsf0iRoTuLfA2HmnqgK3fPWGI1lbKHMN1JF/5f FXbiuzmwPTiGPMxycYs+M9jfXn1p3c/hMnU0WU2CqKxepaWo3OyXh0UnnY8KVuq3E9 tB5F+qzs6UBoq2LNUrvzXz87NohSeeumLXc+Cnns= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Tony Luck , Zhang Rui , "Rafael J. Wysocki" , Thomas Gleixner , Thadeu Lima de Souza Cascardo Subject: [PATCH 4.9 03/20] x86/cpu: Add Jasper Lake to Intel family Date: Tue, 14 Jun 2022 20:39:46 +0200 Message-Id: <20220614183722.905713879@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220614183722.061550591@linuxfoundation.org> References: <20220614183722.061550591@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Zhang Rui commit b2d32af0bff402b4c1fce28311759dd1f6af058a upstream. Japser Lake is an Atom family processor. It uses Tremont cores and is targeted at mobile platforms. Reviewed-by: Tony Luck Signed-off-by: Zhang Rui Signed-off-by: Rafael J. Wysocki Signed-off-by: Thomas Gleixner Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/x86/include/asm/intel-family.h | 1 + 1 file changed, 1 insertion(+) --- a/arch/x86/include/asm/intel-family.h +++ b/arch/x86/include/asm/intel-family.h @@ -70,6 +70,7 @@ =20 #define INTEL_FAM6_ATOM_TREMONT_X 0x86 /* Jacobsville */ #define INTEL_FAM6_ATOM_TREMONT 0x96 /* Elkhart Lake */ +#define INTEL_FAM6_ATOM_TREMONT_L 0x9C /* Jasper Lake */ =20 /* Xeon Phi */ From nobody Mon Apr 27 10:04:57 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2AF0BCCA47A for ; Tue, 14 Jun 2022 18:42:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357196AbiFNSmZ (ORCPT ); Tue, 14 Jun 2022 14:42:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58318 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357107AbiFNSlv (ORCPT ); Tue, 14 Jun 2022 14:41:51 -0400 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E0677496B5; Tue, 14 Jun 2022 11:41:38 -0700 (PDT) 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 sin.source.kernel.org (Postfix) with ESMTPS id 30D98CE1C03; Tue, 14 Jun 2022 18:41:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AF01FC3411B; Tue, 14 Jun 2022 18:41:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1655232095; bh=O4dJF5JLbAqJkMTHNGlx2w5PLAWNKicogAva30Pq3ow=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FMjJhHxrSl95aubt2lEvu90b/GJSWuR+W+Tb1/FWX7paOHIMSKtok7gyk/Kc23VV5 9jCZZhM+BvcOzKbV2c/VBRLe6oobX/PU/EvN4uvkU+m8JVpQX7YaXtzgJjYiiJSw7g zZh4U7lR00qhH07eYg0iKwquDVEXqqg5BkD3/TVk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dave Hansen , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Tony Luck , Megha Dey , Rajneesh Bhardwaj , Andy Shevchenko , Thadeu Lima de Souza Cascardo Subject: [PATCH 4.9 04/20] x86/cpu: Add Cannonlake to Intel family Date: Tue, 14 Jun 2022 20:39:47 +0200 Message-Id: <20220614183723.128868889@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220614183722.061550591@linuxfoundation.org> References: <20220614183722.061550591@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Rajneesh Bhardwaj commit 850eb9fba3711e98bafebde26675d9c082c0ff48 upstream. Add CPUID of Cannonlake (CNL) processors to Intel family list. Cc: Dave Hansen Cc: Thomas Gleixner cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x86@kernel.org Reviewed-by: Thomas Gleixner Suggested-by: Tony Luck Signed-off-by: Megha Dey Signed-off-by: Rajneesh Bhardwaj Signed-off-by: Andy Shevchenko Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/x86/include/asm/intel-family.h | 6 ++++++ 1 file changed, 6 insertions(+) --- a/arch/x86/include/asm/intel-family.h +++ b/arch/x86/include/asm/intel-family.h @@ -9,6 +9,10 @@ * * Things ending in "2" are usually because we have no better * name for them. There's no processor called "SILVERMONT2". + * + * While adding a new CPUID for a new microarchitecture, add a new + * group to keep logically sorted out in chronological order. Within + * that group keep the CPUID for the variants sorted by model number. */ =20 #define INTEL_FAM6_CORE_YONAH 0x0E @@ -48,6 +52,8 @@ #define INTEL_FAM6_KABYLAKE_MOBILE 0x8E #define INTEL_FAM6_KABYLAKE_DESKTOP 0x9E =20 +#define INTEL_FAM6_CANNONLAKE_MOBILE 0x66 + /* "Small Core" Processors (Atom) */ =20 #define INTEL_FAM6_ATOM_BONNELL 0x1C /* Diamondville, Pineview */ From nobody Mon Apr 27 10:04:57 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5F2D8C43334 for ; Tue, 14 Jun 2022 18:42:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357124AbiFNSm3 (ORCPT ); Tue, 14 Jun 2022 14:42:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59438 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357112AbiFNSlv (ORCPT ); Tue, 14 Jun 2022 14:41:51 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A56274AE0E; Tue, 14 Jun 2022 11:41:40 -0700 (PDT) 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 586B9B8186A; Tue, 14 Jun 2022 18:41:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 72894C3411D; Tue, 14 Jun 2022 18:41:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1655232098; bh=jQYiJ2B/yh0n5o1YR+tVEwoIRowRhZ8d7T3D5XSYiqk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fYI5PJRJw1rTG9g09fKkdsx/MrghZjYPt8dW7Om8F6vpjsLE1VYSDPgL6Lt/O+ymA dJQ/9/4UD0rA7FKW0bC9mcc7sSFim+G4ChTCehZeziG++FXSXYGhlb/2FmYYH5joCL SV9ezOvR8CcUYMIKvGvKqvoat5WDid1hXNXRUY/Q= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Rajneesh Bhardwaj , Borislav Petkov , Andy Shevchenko , Dave Hansen , "David E. Box" , dvhart@infradead.org, "H. Peter Anvin" , Ingo Molnar , Kan Liang , Peter Zijlstra , platform-driver-x86@vger.kernel.org, Qiuxu Zhuo , Srinivas Pandruvada , Thomas Gleixner , x86-ml , Thadeu Lima de Souza Cascardo Subject: [PATCH 4.9 05/20] x86/CPU: Add Icelake model number Date: Tue, 14 Jun 2022 20:39:48 +0200 Message-Id: <20220614183723.380508297@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220614183722.061550591@linuxfoundation.org> References: <20220614183722.061550591@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Rajneesh Bhardwaj commit 8cd8f0ce0d6aafe661cb3d6781c8b82bc696c04d upstream. Add the CPUID model number of Icelake (ICL) mobile processors to the Intel family list. Icelake U/Y series uses model number 0x7E. Signed-off-by: Rajneesh Bhardwaj Signed-off-by: Borislav Petkov Cc: Andy Shevchenko Cc: Dave Hansen Cc: "David E. Box" Cc: dvhart@infradead.org Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Kan Liang Cc: Peter Zijlstra Cc: platform-driver-x86@vger.kernel.org Cc: Qiuxu Zhuo Cc: Srinivas Pandruvada Cc: Thomas Gleixner Cc: x86-ml Link: https://lkml.kernel.org/r/20190214115712.19642-2-rajneesh.bhardwaj@li= nux.intel.com Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/x86/include/asm/intel-family.h | 2 ++ 1 file changed, 2 insertions(+) --- a/arch/x86/include/asm/intel-family.h +++ b/arch/x86/include/asm/intel-family.h @@ -54,6 +54,8 @@ =20 #define INTEL_FAM6_CANNONLAKE_MOBILE 0x66 =20 +#define INTEL_FAM6_ICELAKE_MOBILE 0x7E + /* "Small Core" Processors (Atom) */ =20 #define INTEL_FAM6_ATOM_BONNELL 0x1C /* Diamondville, Pineview */ From nobody Mon Apr 27 10:04:57 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 85D1CC43334 for ; Tue, 14 Jun 2022 18:42:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357171AbiFNSmn (ORCPT ); Tue, 14 Jun 2022 14:42:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59204 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1356977AbiFNSlv (ORCPT ); Tue, 14 Jun 2022 14:41:51 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 67F1C4AE2A; Tue, 14 Jun 2022 11:41:43 -0700 (PDT) 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 12EFAB81AF2; Tue, 14 Jun 2022 18:41:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 30691C3411B; Tue, 14 Jun 2022 18:41:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1655232100; bh=jwwEt+L5RB0tfcsHAiWW/CuISh5YmTMs+vSZO81HeKo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jPm8VXi9efH9dJ5NPTDRGriT8NvuPh3wsOPAKtr18TRS0JQ7SEz6P3rJvESq+kcaF RBZDUzs09GU/WByMsmyDv4TLOr1IPsls/GVCNxwRkM8c+qhcWnz5SdUQbl8yi9xsE7 q2OAnKPnxEYyBok0/X/GCxyvuL4l9SJMgeKOu7FA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kan Liang , Borislav Petkov , "H. Peter Anvin" , Andy Shevchenko , Ingo Molnar , Peter Zijlstra , Qiuxu Zhuo , Rajneesh Bhardwaj , rui.zhang@intel.com, Thomas Gleixner , Tony Luck , x86-ml , Thadeu Lima de Souza Cascardo Subject: [PATCH 4.9 06/20] x86/CPU: Add more Icelake model numbers Date: Tue, 14 Jun 2022 20:39:49 +0200 Message-Id: <20220614183723.618521215@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220614183722.061550591@linuxfoundation.org> References: <20220614183722.061550591@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Kan Liang commit e35faeb64146f2015f2aec14b358ae508e4066db upstream. Add the CPUID model numbers of Icelake (ICL) desktop and server processors to the Intel family list. [ Qiuxu: Sort the macros by model number. ] Signed-off-by: Kan Liang Signed-off-by: Borislav Petkov Cc: "H. Peter Anvin" Cc: Andy Shevchenko Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Qiuxu Zhuo Cc: Rajneesh Bhardwaj Cc: rui.zhang@intel.com Cc: Thomas Gleixner Cc: Tony Luck Cc: x86-ml Link: https://lkml.kernel.org/r/20190603134122.13853-1-kan.liang@linux.inte= l.com Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/x86/include/asm/intel-family.h | 3 +++ 1 file changed, 3 insertions(+) --- a/arch/x86/include/asm/intel-family.h +++ b/arch/x86/include/asm/intel-family.h @@ -54,6 +54,9 @@ =20 #define INTEL_FAM6_CANNONLAKE_MOBILE 0x66 =20 +#define INTEL_FAM6_ICELAKE_X 0x6A +#define INTEL_FAM6_ICELAKE_XEON_D 0x6C +#define INTEL_FAM6_ICELAKE_DESKTOP 0x7D #define INTEL_FAM6_ICELAKE_MOBILE 0x7E =20 /* "Small Core" Processors (Atom) */ From nobody Mon Apr 27 10:04:57 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4D9E8CCA47A for ; Tue, 14 Jun 2022 18:42:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357230AbiFNSmc (ORCPT ); Tue, 14 Jun 2022 14:42:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58540 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345408AbiFNSmH (ORCPT ); Tue, 14 Jun 2022 14:42:07 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 006364B1CE; Tue, 14 Jun 2022 11:41:45 -0700 (PDT) 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 AFBB5B8186A; Tue, 14 Jun 2022 18:41:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E0FBFC3411E; Tue, 14 Jun 2022 18:41:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1655232103; bh=5kWMu3VuyNkkAZqF21PQ9b2hFvknVLt8Zm9aKs3pHyU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SngsUiDb6ofvab9fwotgPtuXleL0bhnHIsadTkqLqNfyOWtV+/dVysrB7Q0+HyVWL ZLK3ERYQMsv6xIhwsz9/tsfoBc/rmKDsvl/ia2pvBk0QIrGnJICwIVuMyaXWOWb5Fo KJ/+j3ONYG1bNFO5FNiLetmJp2SLT065QnZUh70I= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kan Liang , Borislav Petkov , Tony Luck , ak@linux.intel.com, "H. Peter Anvin" , Ingo Molnar , Peter Zijlstra , Thomas Gleixner , x86-ml , Thadeu Lima de Souza Cascardo Subject: [PATCH 4.9 07/20] x86/cpu: Add Comet Lake to the Intel CPU models header Date: Tue, 14 Jun 2022 20:39:50 +0200 Message-Id: <20220614183723.858445210@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220614183722.061550591@linuxfoundation.org> References: <20220614183722.061550591@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Kan Liang commit 8d7c6ac3b2371eb1cbc9925a88f4d10efff374de upstream. Comet Lake is the new 10th Gen Intel processor. Add two new CPU model numbers to the Intel family list. The CPU model numbers are not published in the SDM yet but they come from an authoritative internal source. [ bp: Touch up commit message. ] Signed-off-by: Kan Liang Signed-off-by: Borislav Petkov Reviewed-by: Tony Luck Cc: ak@linux.intel.com Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: x86-ml Link: https://lkml.kernel.org/r/1570549810-25049-2-git-send-email-kan.liang= @linux.intel.com Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/x86/include/asm/intel-family.h | 3 +++ 1 file changed, 3 insertions(+) --- a/arch/x86/include/asm/intel-family.h +++ b/arch/x86/include/asm/intel-family.h @@ -59,6 +59,9 @@ #define INTEL_FAM6_ICELAKE_DESKTOP 0x7D #define INTEL_FAM6_ICELAKE_MOBILE 0x7E =20 +#define INTEL_FAM6_COMETLAKE 0xA5 +#define INTEL_FAM6_COMETLAKE_L 0xA6 + /* "Small Core" Processors (Atom) */ =20 #define INTEL_FAM6_ATOM_BONNELL 0x1C /* Diamondville, Pineview */ From nobody Mon Apr 27 10:04:57 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 41D26C43334 for ; Tue, 14 Jun 2022 18:42:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357161AbiFNSml (ORCPT ); Tue, 14 Jun 2022 14:42:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58452 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357125AbiFNSlx (ORCPT ); Tue, 14 Jun 2022 14:41:53 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 36C4449B59; Tue, 14 Jun 2022 11:41:47 -0700 (PDT) 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 dfw.source.kernel.org (Postfix) with ESMTPS id 9E14A617C4; Tue, 14 Jun 2022 18:41:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AA6E3C3411B; Tue, 14 Jun 2022 18:41:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1655232106; bh=G3gCe1v8urjVgyfnmmNq0OgS8R6JQrgw2oa7cbLvIsI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=vfJiosncS0hoXxTwtZQUg0wwdHPOvQiqzdXesT4Xpmtn3eMBl9n6cAo0xYMw3Dabc GKeeSmKXINENq0PPHjcw/QHjBDRSBC4gKvFnhZfUqyiWbdc8m2eY/N91uiCz1Vmv46 j8fSDdLtdTYcSNOJ0ZrtDKQkq9B9ZKPRpaucME5g= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Tony Luck , Ingo Molnar , Thadeu Lima de Souza Cascardo Subject: [PATCH 4.9 08/20] x86/cpu: Add Lakefield, Alder Lake and Rocket Lake models to the to Intel CPU family Date: Tue, 14 Jun 2022 20:39:51 +0200 Message-Id: <20220614183724.095465386@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220614183722.061550591@linuxfoundation.org> References: <20220614183722.061550591@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Tony Luck commit e00b62f0b06d0ae2b844049f216807617aff0cdb upstream. Add three new Intel CPU models. Signed-off-by: Tony Luck Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20200721043749.31567-1-tony.luck@intel.com Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/x86/include/asm/intel-family.h | 7 +++++++ 1 file changed, 7 insertions(+) --- a/arch/x86/include/asm/intel-family.h +++ b/arch/x86/include/asm/intel-family.h @@ -62,6 +62,13 @@ #define INTEL_FAM6_COMETLAKE 0xA5 #define INTEL_FAM6_COMETLAKE_L 0xA6 =20 +#define INTEL_FAM6_ROCKETLAKE 0xA7 + +/* Hybrid Core/Atom Processors */ + +#define INTEL_FAM6_LAKEFIELD 0x8A +#define INTEL_FAM6_ALDERLAKE 0x97 + /* "Small Core" Processors (Atom) */ =20 #define INTEL_FAM6_ATOM_BONNELL 0x1C /* Diamondville, Pineview */ From nobody Mon Apr 27 10:04:57 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D2ECDC433EF for ; Tue, 14 Jun 2022 18:42:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357178AbiFNSmw (ORCPT ); Tue, 14 Jun 2022 14:42:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59166 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347374AbiFNSmU (ORCPT ); Tue, 14 Jun 2022 14:42:20 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 973424992C; Tue, 14 Jun 2022 11:41:51 -0700 (PDT) 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 280BFB81AEC; Tue, 14 Jun 2022 18:41:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 70645C3411D; Tue, 14 Jun 2022 18:41:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1655232108; bh=aeVpXKbqdQ5mK8L5Tc3oxflXliKoE2X0ydk71CIoT28=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=zC63BLgS/jOg0x+UDsBzgkytblvODVJP91QIT3n6UGvt15xJNybuNKI3v5OrCuE07 ul5/Cj2Or2gm4D+EWz8J3XT7p1q9U5EBiZ4+2TV2MfUDPtqg3keYhtV2xgn5j/8AcA LXMTbcEvx48/Z68Cw22Uee06J4RqHHfSo0wuwvV4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Gayatri Kammela , Tony Luck , Borislav Petkov , Thomas Gleixner , Thadeu Lima de Souza Cascardo Subject: [PATCH 4.9 09/20] x86/cpu: Add another Alder Lake CPU to the Intel family Date: Tue, 14 Jun 2022 20:39:52 +0200 Message-Id: <20220614183724.312334964@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220614183722.061550591@linuxfoundation.org> References: <20220614183722.061550591@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Gayatri Kammela commit 6e1239c13953f3c2a76e70031f74ddca9ae57cd3 upstream. Add Alder Lake mobile CPU model number to Intel family. Signed-off-by: Gayatri Kammela Signed-off-by: Tony Luck Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/20210121215004.11618-1-tony.luck@intel.com Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/x86/include/asm/intel-family.h | 1 + 1 file changed, 1 insertion(+) --- a/arch/x86/include/asm/intel-family.h +++ b/arch/x86/include/asm/intel-family.h @@ -68,6 +68,7 @@ =20 #define INTEL_FAM6_LAKEFIELD 0x8A #define INTEL_FAM6_ALDERLAKE 0x97 +#define INTEL_FAM6_ALDERLAKE_L 0x9A =20 /* "Small Core" Processors (Atom) */ From nobody Mon Apr 27 10:04:57 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C3D09CCA47A for ; Tue, 14 Jun 2022 18:43:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357080AbiFNSnD (ORCPT ); Tue, 14 Jun 2022 14:43:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58446 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1356981AbiFNSmY (ORCPT ); Tue, 14 Jun 2022 14:42:24 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 68D374A3D6; Tue, 14 Jun 2022 11:41:54 -0700 (PDT) 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 03C40B81AEE; Tue, 14 Jun 2022 18:41:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 50EF4C3411E; Tue, 14 Jun 2022 18:41:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1655232111; bh=T2GvToOkGqZLFmoAoZx1VgDivv9LfvzLb4jyvzC1efU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=aKi4U30LZmIh4IthrcGHTmJDR2sQl1EhRM6ubpnncJkbFXywJtBv/cTnE7grkDAFi RUbdeNEXSzyWmeXO1MthxvEzPIxBAKwdxW7DB8KPPzsC0ANfXY5DRi/iNyh7q89HXw my0+I97dM4gN7L9/7tv6B8EERPy25OMB3EqrZ4iY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Pawan Gupta , Borislav Petkov , Thomas Gleixner , Thadeu Lima de Souza Cascardo Subject: [PATCH 4.9 10/20] Documentation: Add documentation for Processor MMIO Stale Data Date: Tue, 14 Jun 2022 20:39:53 +0200 Message-Id: <20220614183724.537487221@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220614183722.061550591@linuxfoundation.org> References: <20220614183722.061550591@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Pawan Gupta commit 4419470191386456e0b8ed4eb06a70b0021798a6 upstream Add the admin guide for Processor MMIO stale data vulnerabilities. Signed-off-by: Pawan Gupta Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner [cascardo: index.rst conflict fixup] Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- Documentation/hw-vuln/index.rst | 1=20 Documentation/hw-vuln/processor_mmio_stale_data.rst | 246 +++++++++++++++= +++++ 2 files changed, 247 insertions(+) create mode 100644 Documentation/hw-vuln/processor_mmio_stale_data.rst --- a/Documentation/hw-vuln/index.rst +++ b/Documentation/hw-vuln/index.rst @@ -15,3 +15,4 @@ are configurable at compile, boot or run tsx_async_abort multihit special-register-buffer-data-sampling + processor_mmio_stale_data --- /dev/null +++ b/Documentation/hw-vuln/processor_mmio_stale_data.rst @@ -0,0 +1,246 @@ +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +Processor MMIO Stale Data Vulnerabilities +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +Processor MMIO Stale Data Vulnerabilities are a class of memory-mapped I/O +(MMIO) vulnerabilities that can expose data. The sequences of operations f= or +exposing data range from simple to very complex. Because most of the +vulnerabilities require the attacker to have access to MMIO, many environm= ents +are not affected. System environments using virtualization where MMIO acce= ss is +provided to untrusted guests may need mitigation. These vulnerabilities are +not transient execution attacks. However, these vulnerabilities may propag= ate +stale data into core fill buffers where the data can subsequently be infer= red +by an unmitigated transient execution attack. Mitigation for these +vulnerabilities includes a combination of microcode update and software +changes, depending on the platform and usage model. Some of these mitigati= ons +are similar to those used to mitigate Microarchitectural Data Sampling (MD= S) or +those used to mitigate Special Register Buffer Data Sampling (SRBDS). + +Data Propagators +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +Propagators are operations that result in stale data being copied or moved= from +one microarchitectural buffer or register to another. Processor MMIO Stale= Data +Vulnerabilities are operations that may result in stale data being directly +read into an architectural, software-visible state or sampled from a buffe= r or +register. + +Fill Buffer Stale Data Propagator (FBSDP) +----------------------------------------- +Stale data may propagate from fill buffers (FB) into the non-coherent port= ion +of the uncore on some non-coherent writes. Fill buffer propagation by itse= lf +does not make stale data architecturally visible. Stale data must be propa= gated +to a location where it is subject to reading or sampling. + +Sideband Stale Data Propagator (SSDP) +------------------------------------- +The sideband stale data propagator (SSDP) is limited to the client (includ= ing +Intel Xeon server E3) uncore implementation. The sideband response buffer = is +shared by all client cores. For non-coherent reads that go to sideband +destinations, the uncore logic returns 64 bytes of data to the core, inclu= ding +both requested data and unrequested stale data, from a transaction buffer = and +the sideband response buffer. As a result, stale data from the sideband +response and transaction buffers may now reside in a core fill buffer. + +Primary Stale Data Propagator (PSDP) +------------------------------------ +The primary stale data propagator (PSDP) is limited to the client (includi= ng +Intel Xeon server E3) uncore implementation. Similar to the sideband respo= nse +buffer, the primary response buffer is shared by all client cores. For some +processors, MMIO primary reads will return 64 bytes of data to the core fi= ll +buffer including both requested data and unrequested stale data. This is +similar to the sideband stale data propagator. + +Vulnerabilities +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +Device Register Partial Write (DRPW) (CVE-2022-21166) +----------------------------------------------------- +Some endpoint MMIO registers incorrectly handle writes that are smaller th= an +the register size. Instead of aborting the write or only copying the corre= ct +subset of bytes (for example, 2 bytes for a 2-byte write), more bytes than +specified by the write transaction may be written to the register. On +processors affected by FBSDP, this may expose stale data from the fill buf= fers +of the core that created the write transaction. + +Shared Buffers Data Sampling (SBDS) (CVE-2022-21125) +---------------------------------------------------- +After propagators may have moved data around the uncore and copied stale d= ata +into client core fill buffers, processors affected by MFBDS can leak data = from +the fill buffer. It is limited to the client (including Intel Xeon server = E3) +uncore implementation. + +Shared Buffers Data Read (SBDR) (CVE-2022-21123) +------------------------------------------------ +It is similar to Shared Buffer Data Sampling (SBDS) except that the data is +directly read into the architectural software-visible state. It is limited= to +the client (including Intel Xeon server E3) uncore implementation. + +Affected Processors +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +Not all the CPUs are affected by all the variants. For instance, most +processors for the server market (excluding Intel Xeon E3 processors) are +impacted by only Device Register Partial Write (DRPW). + +Below is the list of affected Intel processors [#f1]_: + + =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D + Common name Family_Model Steppings + =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D + HASWELL_X 06_3FH 2,4 + SKYLAKE_L 06_4EH 3 + BROADWELL_X 06_4FH All + SKYLAKE_X 06_55H 3,4,6,7,11 + BROADWELL_D 06_56H 3,4,5 + SKYLAKE 06_5EH 3 + ICELAKE_X 06_6AH 4,5,6 + ICELAKE_D 06_6CH 1 + ICELAKE_L 06_7EH 5 + ATOM_TREMONT_D 06_86H All + LAKEFIELD 06_8AH 1 + KABYLAKE_L 06_8EH 9 to 12 + ATOM_TREMONT 06_96H 1 + ATOM_TREMONT_L 06_9CH 0 + KABYLAKE 06_9EH 9 to 13 + COMETLAKE 06_A5H 2,3,5 + COMETLAKE_L 06_A6H 0,1 + ROCKETLAKE 06_A7H 1 + =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D + +If a CPU is in the affected processor list, but not affected by a variant,= it +is indicated by new bits in MSR IA32_ARCH_CAPABILITIES. As described in a = later +section, mitigation largely remains the same for all the variants, i.e. to +clear the CPU fill buffers via VERW instruction. + +New bits in MSRs +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +Newer processors and microcode update on existing affected processors adde= d new +bits to IA32_ARCH_CAPABILITIES MSR. These bits can be used to enumerate +specific variants of Processor MMIO Stale Data vulnerabilities and mitigat= ion +capability. + +MSR IA32_ARCH_CAPABILITIES +-------------------------- +Bit 13 - SBDR_SSDP_NO - When set, processor is not affected by either the + Shared Buffers Data Read (SBDR) vulnerability or the sideband stale + data propagator (SSDP). +Bit 14 - FBSDP_NO - When set, processor is not affected by the Fill Buffer + Stale Data Propagator (FBSDP). +Bit 15 - PSDP_NO - When set, processor is not affected by Primary Stale Da= ta + Propagator (PSDP). +Bit 17 - FB_CLEAR - When set, VERW instruction will overwrite CPU fill buf= fer + values as part of MD_CLEAR operations. Processors that do not + enumerate MDS_NO (meaning they are affected by MDS) but that do + enumerate support for both L1D_FLUSH and MD_CLEAR implicitly enumerate + FB_CLEAR as part of their MD_CLEAR support. +Bit 18 - FB_CLEAR_CTRL - Processor supports read and write to MSR + IA32_MCU_OPT_CTRL[FB_CLEAR_DIS]. On such processors, the FB_CLEAR_DIS + bit can be set to cause the VERW instruction to not perform the + FB_CLEAR action. Not all processors that support FB_CLEAR will support + FB_CLEAR_CTRL. + +MSR IA32_MCU_OPT_CTRL +--------------------- +Bit 3 - FB_CLEAR_DIS - When set, VERW instruction does not perform the FB_= CLEAR +action. This may be useful to reduce the performance impact of FB_CLEAR in +cases where system software deems it warranted (for example, when performa= nce +is more critical, or the untrusted software has no MMIO access). Note that +FB_CLEAR_DIS has no impact on enumeration (for example, it does not change +FB_CLEAR or MD_CLEAR enumeration) and it may not be supported on all proce= ssors +that enumerate FB_CLEAR. + +Mitigation +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +Like MDS, all variants of Processor MMIO Stale Data vulnerabilities have = the +same mitigation strategy to force the CPU to clear the affected buffers be= fore +an attacker can extract the secrets. + +This is achieved by using the otherwise unused and obsolete VERW instructi= on in +combination with a microcode update. The microcode clears the affected CPU +buffers when the VERW instruction is executed. + +Kernel reuses the MDS function to invoke the buffer clearing: + + mds_clear_cpu_buffers() + +On MDS affected CPUs, the kernel already invokes CPU buffer clear on +kernel/userspace, hypervisor/guest and C-state (idle) transitions. No +additional mitigation is needed on such CPUs. + +For CPUs not affected by MDS or TAA, mitigation is needed only for the att= acker +with MMIO capability. Therefore, VERW is not required for kernel/userspace= . For +virtualization case, VERW is only needed at VMENTER for a guest with MMIO +capability. + +Mitigation points +----------------- +Return to user space +^^^^^^^^^^^^^^^^^^^^ +Same mitigation as MDS when affected by MDS/TAA, otherwise no mitigation +needed. + +C-State transition +^^^^^^^^^^^^^^^^^^ +Control register writes by CPU during C-state transition can propagate data +from fill buffer to uncore buffers. Execute VERW before C-state transition= to +clear CPU fill buffers. + +Guest entry point +^^^^^^^^^^^^^^^^^ +Same mitigation as MDS when processor is also affected by MDS/TAA, otherwi= se +execute VERW at VMENTER only for MMIO capable guests. On CPUs not affected= by +MDS/TAA, guest without MMIO access cannot extract secrets using Processor = MMIO +Stale Data vulnerabilities, so there is no need to execute VERW for such g= uests. + +Mitigation control on the kernel command line +--------------------------------------------- +The kernel command line allows to control the Processor MMIO Stale Data +mitigations at boot time with the option "mmio_stale_data=3D". The valid +arguments for this option are: + + =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D + full If the CPU is vulnerable, enable mitigation; CPU buffer clea= ring + on exit to userspace and when entering a VM. Idle transition= s are + protected as well. It does not automatically disable SMT. + full,nosmt Same as full, with SMT disabled on vulnerable CPUs. This is = the + complete mitigation. + off Disables mitigation completely. + =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D + +If the CPU is affected and mmio_stale_data=3Doff is not supplied on the ke= rnel +command line, then the kernel selects the appropriate mitigation. + +Mitigation status information +----------------------------- +The Linux kernel provides a sysfs interface to enumerate the current +vulnerability status of the system: whether the system is vulnerable, and +which mitigations are active. The relevant sysfs file is: + + /sys/devices/system/cpu/vulnerabilities/mmio_stale_data + +The possible values in this file are: + + .. list-table:: + + * - 'Not affected' + - The processor is not vulnerable + * - 'Vulnerable' + - The processor is vulnerable, but no mitigation enabled + * - 'Vulnerable: Clear CPU buffers attempted, no microcode' + - The processor is vulnerable, but microcode is not updated. The + mitigation is enabled on a best effort basis. + * - 'Mitigation: Clear CPU buffers' + - The processor is vulnerable and the CPU buffer clearing mitigatio= n is + enabled. + +If the processor is vulnerable then the following information is appended = to +the above information: + + =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + 'SMT vulnerable' SMT is enabled + 'SMT disabled' SMT is disabled + 'SMT Host state unknown' Kernel runs in a VM, Host SMT state unknown + =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +References +---------- +.. [#f1] Affected Processors + https://www.intel.com/content/www/us/en/developer/topic-technology/soft= ware-security-guidance/processors-affected-consolidated-product-cpu-model.h= tml From nobody Mon Apr 27 10:04:57 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AC899C43334 for ; Tue, 14 Jun 2022 18:41:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345412AbiFNSlR (ORCPT ); Tue, 14 Jun 2022 14:41:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57884 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345367AbiFNSlJ (ORCPT ); Tue, 14 Jun 2022 14:41:09 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 550BB46642; Tue, 14 Jun 2022 11:41:06 -0700 (PDT) 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 0AF0CB81AEE; Tue, 14 Jun 2022 18:41:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 63D02C3411B; Tue, 14 Jun 2022 18:41:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1655232063; bh=CYC3+IkmGso2EMOY3RlRvGGjclAmqPdJj+eBXsPXQ9E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=oKtPWn+CQ7CjbiGHhP/hQUKIP1EeF7N1GxsWmFQi8LJtykNEVSNbgiApgN7SccZWY JsaXHmTOoDVOjZXxaO2Fv4tfaDFpeiQZdxzkg3kSSoBhqzKZazUsNKJBW+QBvM/xEY udOt8ZQL0ZGXoAvHQr7S5r9tfj06KfgD6yoOkRck= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Pawan Gupta , Borislav Petkov , Thomas Gleixner , Thadeu Lima de Souza Cascardo Subject: [PATCH 4.9 11/20] x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug Date: Tue, 14 Jun 2022 20:39:54 +0200 Message-Id: <20220614183724.735199092@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220614183722.061550591@linuxfoundation.org> References: <20220614183722.061550591@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Pawan Gupta commit 51802186158c74a0304f51ab963e7c2b3a2b046f upstream Processor MMIO Stale Data is a class of vulnerabilities that may expose data after an MMIO operation. For more details please refer to Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst Add the Processor MMIO Stale Data bug enumeration. A microcode update adds new bits to the MSR IA32_ARCH_CAPABILITIES, define them. Signed-off-by: Pawan Gupta Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner [cascardo: adapted family names to the ones in v4.19] Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/x86/include/asm/cpufeatures.h | 1=20 arch/x86/include/asm/msr-index.h | 19 ++++++++++++++++ arch/x86/kernel/cpu/common.c | 43 ++++++++++++++++++++++++++++++++= +++-- 3 files changed, 61 insertions(+), 2 deletions(-) --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -362,5 +362,6 @@ #define X86_BUG_TAA X86_BUG(22) /* CPU is affected by TSX Async Abort(TA= A) */ #define X86_BUG_ITLB_MULTIHIT X86_BUG(23) /* CPU may incur MCE during cer= tain page attribute changes */ #define X86_BUG_SRBDS X86_BUG(24) /* CPU may leak RNG bits if not mitiga= ted */ +#define X86_BUG_MMIO_STALE_DATA X86_BUG(25) /* CPU is affected by Process= or MMIO Stale Data vulnerabilities */ =20 #endif /* _ASM_X86_CPUFEATURES_H */ --- a/arch/x86/include/asm/msr-index.h +++ b/arch/x86/include/asm/msr-index.h @@ -89,6 +89,25 @@ * Not susceptible to * TSX Async Abort (TAA) vulnerabilities. */ +#define ARCH_CAP_SBDR_SSDP_NO BIT(13) /* + * Not susceptible to SBDR and SSDP + * variants of Processor MMIO stale data + * vulnerabilities. + */ +#define ARCH_CAP_FBSDP_NO BIT(14) /* + * Not susceptible to FBSDP variant of + * Processor MMIO stale data + * vulnerabilities. + */ +#define ARCH_CAP_PSDP_NO BIT(15) /* + * Not susceptible to PSDP variant of + * Processor MMIO stale data + * vulnerabilities. + */ +#define ARCH_CAP_FB_CLEAR BIT(17) /* + * VERW clears CPU fill buffer + * even on MDS_NO CPUs. + */ =20 #define MSR_IA32_FLUSH_CMD 0x0000010b #define L1D_FLUSH BIT(0) /* --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -962,18 +962,39 @@ static const __initconst struct x86_cpu_ X86_FEATURE_ANY, issues) =20 #define SRBDS BIT(0) +/* CPU is affected by X86_BUG_MMIO_STALE_DATA */ +#define MMIO BIT(1) =20 static const struct x86_cpu_id cpu_vuln_blacklist[] __initconst =3D { VULNBL_INTEL_STEPPINGS(IVYBRIDGE, X86_STEPPING_ANY, SRBDS), VULNBL_INTEL_STEPPINGS(HASWELL_CORE, X86_STEPPING_ANY, SRBDS), VULNBL_INTEL_STEPPINGS(HASWELL_ULT, X86_STEPPING_ANY, SRBDS), VULNBL_INTEL_STEPPINGS(HASWELL_GT3E, X86_STEPPING_ANY, SRBDS), + VULNBL_INTEL_STEPPINGS(HASWELL_X, BIT(2) | BIT(4), MMIO), + VULNBL_INTEL_STEPPINGS(BROADWELL_XEON_D,X86_STEPPINGS(0x3, 0x5), MMIO), VULNBL_INTEL_STEPPINGS(BROADWELL_GT3E, X86_STEPPING_ANY, SRBDS), + VULNBL_INTEL_STEPPINGS(BROADWELL_X, X86_STEPPING_ANY, MMIO), VULNBL_INTEL_STEPPINGS(BROADWELL_CORE, X86_STEPPING_ANY, SRBDS), + VULNBL_INTEL_STEPPINGS(SKYLAKE_MOBILE, X86_STEPPINGS(0x3, 0x3), SRBDS | M= MIO), VULNBL_INTEL_STEPPINGS(SKYLAKE_MOBILE, X86_STEPPING_ANY, SRBDS), + VULNBL_INTEL_STEPPINGS(SKYLAKE_X, BIT(3) | BIT(4) | BIT(6) | + BIT(7) | BIT(0xB), MMIO), + VULNBL_INTEL_STEPPINGS(SKYLAKE_DESKTOP, X86_STEPPINGS(0x3, 0x3), SRBDS | = MMIO), VULNBL_INTEL_STEPPINGS(SKYLAKE_DESKTOP, X86_STEPPING_ANY, SRBDS), - VULNBL_INTEL_STEPPINGS(KABYLAKE_MOBILE, X86_STEPPINGS(0x0, 0xC), SRBDS), - VULNBL_INTEL_STEPPINGS(KABYLAKE_DESKTOP,X86_STEPPINGS(0x0, 0xD), SRBDS), + VULNBL_INTEL_STEPPINGS(KABYLAKE_MOBILE, X86_STEPPINGS(0x9, 0xC), SRBDS | = MMIO), + VULNBL_INTEL_STEPPINGS(KABYLAKE_MOBILE, X86_STEPPINGS(0x0, 0x8), SRBDS), + VULNBL_INTEL_STEPPINGS(KABYLAKE_DESKTOP,X86_STEPPINGS(0x9, 0xD), SRBDS | = MMIO), + VULNBL_INTEL_STEPPINGS(KABYLAKE_DESKTOP,X86_STEPPINGS(0x0, 0x8), SRBDS), + VULNBL_INTEL_STEPPINGS(ICELAKE_MOBILE, X86_STEPPINGS(0x5, 0x5), MMIO), + VULNBL_INTEL_STEPPINGS(ICELAKE_XEON_D, X86_STEPPINGS(0x1, 0x1), MMIO), + VULNBL_INTEL_STEPPINGS(ICELAKE_X, X86_STEPPINGS(0x4, 0x6), MMIO), + VULNBL_INTEL_STEPPINGS(COMETLAKE, BIT(2) | BIT(3) | BIT(5), MMIO), + VULNBL_INTEL_STEPPINGS(COMETLAKE_L, X86_STEPPINGS(0x0, 0x1), MMIO), + VULNBL_INTEL_STEPPINGS(LAKEFIELD, X86_STEPPINGS(0x1, 0x1), MMIO), + VULNBL_INTEL_STEPPINGS(ROCKETLAKE, X86_STEPPINGS(0x1, 0x1), MMIO), + VULNBL_INTEL_STEPPINGS(ATOM_TREMONT, X86_STEPPINGS(0x1, 0x1), MMIO), + VULNBL_INTEL_STEPPINGS(ATOM_TREMONT_X, X86_STEPPING_ANY, MMIO), + VULNBL_INTEL_STEPPINGS(ATOM_TREMONT_L, X86_STEPPINGS(0x0, 0x0), MMIO), {} }; =20 @@ -994,6 +1015,13 @@ u64 x86_read_arch_cap_msr(void) return ia32_cap; } =20 +static bool arch_cap_mmio_immune(u64 ia32_cap) +{ + return (ia32_cap & ARCH_CAP_FBSDP_NO && + ia32_cap & ARCH_CAP_PSDP_NO && + ia32_cap & ARCH_CAP_SBDR_SSDP_NO); +} + static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c) { u64 ia32_cap =3D x86_read_arch_cap_msr(); @@ -1051,6 +1079,17 @@ static void __init cpu_set_bug_bits(stru cpu_matches(cpu_vuln_blacklist, SRBDS)) setup_force_cpu_bug(X86_BUG_SRBDS); =20 + /* + * Processor MMIO Stale Data bug enumeration + * + * Affected CPU list is generally enough to enumerate the vulnerability, + * but for virtualization case check for ARCH_CAP MSR bits also, VMM may + * not want the guest to enumerate the bug. + */ + if (cpu_matches(cpu_vuln_blacklist, MMIO) && + !arch_cap_mmio_immune(ia32_cap)) + setup_force_cpu_bug(X86_BUG_MMIO_STALE_DATA); + if (cpu_matches(cpu_vuln_whitelist, NO_MELTDOWN)) return; From nobody Mon Apr 27 10:04:57 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A3205C43334 for ; Tue, 14 Jun 2022 18:41:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1355935AbiFNSlV (ORCPT ); Tue, 14 Jun 2022 14:41:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57928 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345350AbiFNSlK (ORCPT ); Tue, 14 Jun 2022 14:41:10 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2AB45496B5; Tue, 14 Jun 2022 11:41:09 -0700 (PDT) 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 D9A34B81AF4; Tue, 14 Jun 2022 18:41:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 36750C3411B; Tue, 14 Jun 2022 18:41:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1655232066; bh=PjmGR9n1oGUqUe7GQOEk8mD86PluZ5gf7mkSBY50Wt0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gKJOOxfwHrGV4JhT9v+FhquBgxfNztZbJjf4uf+a+squFzBMeFpkXawX8vsWjmBsy VxTJtK4zTUAGCtisGxb6ef1/3/rdegVJ6RJF7zfUcjukYKoiTQPDB3u6GrCbeBqwUu Zo+l484aSQ27MP+rPRaQ4Ssh3oJxUVdEF4hk/QE4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Pawan Gupta , Borislav Petkov , Thomas Gleixner , Thadeu Lima de Souza Cascardo Subject: [PATCH 4.9 12/20] x86/speculation: Add a common function for MD_CLEAR mitigation update Date: Tue, 14 Jun 2022 20:39:55 +0200 Message-Id: <20220614183724.941735289@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220614183722.061550591@linuxfoundation.org> References: <20220614183722.061550591@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Pawan Gupta commit f52ea6c26953fed339aa4eae717ee5c2133c7ff2 upstream Processor MMIO Stale Data mitigation uses similar mitigation as MDS and TAA. In preparation for adding its mitigation, add a common function to update all mitigations that depend on MD_CLEAR. [ bp: Add a newline in md_clear_update_mitigation() to separate statements better. ] Signed-off-by: Pawan Gupta Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/x86/kernel/cpu/bugs.c | 59 +++++++++++++++++++++++++---------------= ----- 1 file changed, 33 insertions(+), 26 deletions(-) --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -39,7 +39,7 @@ static void __init spectre_v2_select_mit static void __init ssb_select_mitigation(void); static void __init l1tf_select_mitigation(void); static void __init mds_select_mitigation(void); -static void __init mds_print_mitigation(void); +static void __init md_clear_update_mitigation(void); static void __init taa_select_mitigation(void); static void __init srbds_select_mitigation(void); =20 @@ -112,10 +112,10 @@ void __init check_bugs(void) srbds_select_mitigation(); =20 /* - * As MDS and TAA mitigations are inter-related, print MDS - * mitigation until after TAA mitigation selection is done. + * As MDS and TAA mitigations are inter-related, update and print their + * mitigation after TAA mitigation selection is done. */ - mds_print_mitigation(); + md_clear_update_mitigation(); =20 arch_smt_update(); =20 @@ -256,14 +256,6 @@ static void __init mds_select_mitigation } } =20 -static void __init mds_print_mitigation(void) -{ - if (!boot_cpu_has_bug(X86_BUG_MDS) || cpu_mitigations_off()) - return; - - pr_info("%s\n", mds_strings[mds_mitigation]); -} - static int __init mds_cmdline(char *str) { if (!boot_cpu_has_bug(X86_BUG_MDS)) @@ -311,7 +303,7 @@ static void __init taa_select_mitigation /* TSX previously disabled by tsx=3Doff */ if (!boot_cpu_has(X86_FEATURE_RTM)) { taa_mitigation =3D TAA_MITIGATION_TSX_DISABLED; - goto out; + return; } =20 if (cpu_mitigations_off()) { @@ -325,7 +317,7 @@ static void __init taa_select_mitigation */ if (taa_mitigation =3D=3D TAA_MITIGATION_OFF && mds_mitigation =3D=3D MDS_MITIGATION_OFF) - goto out; + return; =20 if (boot_cpu_has(X86_FEATURE_MD_CLEAR)) taa_mitigation =3D TAA_MITIGATION_VERW; @@ -357,18 +349,6 @@ static void __init taa_select_mitigation =20 if (taa_nosmt || cpu_mitigations_auto_nosmt()) cpu_smt_disable(false); - - /* - * Update MDS mitigation, if necessary, as the mds_user_clear is - * now enabled for TAA mitigation. - */ - if (mds_mitigation =3D=3D MDS_MITIGATION_OFF && - boot_cpu_has_bug(X86_BUG_MDS)) { - mds_mitigation =3D MDS_MITIGATION_FULL; - mds_select_mitigation(); - } -out: - pr_info("%s\n", taa_strings[taa_mitigation]); } =20 static int __init tsx_async_abort_parse_cmdline(char *str) @@ -393,6 +373,33 @@ static int __init tsx_async_abort_parse_ early_param("tsx_async_abort", tsx_async_abort_parse_cmdline); =20 #undef pr_fmt +#define pr_fmt(fmt) "" fmt + +static void __init md_clear_update_mitigation(void) +{ + if (cpu_mitigations_off()) + return; + + if (!static_key_enabled(&mds_user_clear)) + goto out; + + /* + * mds_user_clear is now enabled. Update MDS mitigation, if + * necessary. + */ + if (mds_mitigation =3D=3D MDS_MITIGATION_OFF && + boot_cpu_has_bug(X86_BUG_MDS)) { + mds_mitigation =3D MDS_MITIGATION_FULL; + mds_select_mitigation(); + } +out: + if (boot_cpu_has_bug(X86_BUG_MDS)) + pr_info("MDS: %s\n", mds_strings[mds_mitigation]); + if (boot_cpu_has_bug(X86_BUG_TAA)) + pr_info("TAA: %s\n", taa_strings[taa_mitigation]); +} + +#undef pr_fmt #define pr_fmt(fmt) "SRBDS: " fmt =20 enum srbds_mitigations { From nobody Mon Apr 27 10:04:57 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B08EEC433EF for ; Tue, 14 Jun 2022 18:41:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1356761AbiFNSl0 (ORCPT ); Tue, 14 Jun 2022 14:41:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57884 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237929AbiFNSlP (ORCPT ); Tue, 14 Jun 2022 14:41:15 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7654D4969A; Tue, 14 Jun 2022 11:41:10 -0700 (PDT) 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 dfw.source.kernel.org (Postfix) with ESMTPS id F10DE617BA; Tue, 14 Jun 2022 18:41:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0F01CC3411B; Tue, 14 Jun 2022 18:41:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1655232069; bh=Rqq9+DO+DobFf4tu+gR1FqFD8iuaKGeVDVzjS+WGB1w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=e45Y9Ix9WUFYRM+CNgmPYiX/cy84k7UvuSIlYMdKWoGzmuusMbdx0yAmZ3zTS52qg p4noF3PfPqIoBoPCfn/DDi/6lEB4THnhVXG41/s0EBbqhBRlbxvVZayq1FCFuWnkKL pQ2hS1SwnmNNhgV2uxcRQ0jJroPmXbFYpEJVnHaw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Pawan Gupta , Borislav Petkov , Thomas Gleixner , Thadeu Lima de Souza Cascardo Subject: [PATCH 4.9 13/20] x86/speculation/mmio: Add mitigation for Processor MMIO Stale Data Date: Tue, 14 Jun 2022 20:39:56 +0200 Message-Id: <20220614183725.181834522@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220614183722.061550591@linuxfoundation.org> References: <20220614183722.061550591@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Pawan Gupta commit 8cb861e9e3c9a55099ad3d08e1a3b653d29c33ca upstream Processor MMIO Stale Data is a class of vulnerabilities that may expose data after an MMIO operation. For details please refer to Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst. These vulnerabilities are broadly categorized as: Device Register Partial Write (DRPW): Some endpoint MMIO registers incorrectly handle writes that are smaller than the register size. Instead of aborting the write or only copying the correct subset of bytes (for example, 2 bytes for a 2-byte write), more bytes than specified by the write transaction may be written to the register. On some processors, this may expose stale data from the fill buffers of the core that created the write transaction. Shared Buffers Data Sampling (SBDS): After propagators may have moved data around the uncore and copied stale data into client core fill buffers, processors affected by MFBDS can leak data from the fill buffer. Shared Buffers Data Read (SBDR): It is similar to Shared Buffer Data Sampling (SBDS) except that the data is directly read into the architectural software-visible state. An attacker can use these vulnerabilities to extract data from CPU fill buffers using MDS and TAA methods. Mitigate it by clearing the CPU fill buffers using the VERW instruction before returning to a user or a guest. On CPUs not affected by MDS and TAA, user application cannot sample data from CPU fill buffers using MDS or TAA. A guest with MMIO access can still use DRPW or SBDR to extract data architecturally. Mitigate it with VERW instruction to clear fill buffers before VMENTER for MMIO capable guests. Add a kernel parameter mmio_stale_data=3D{off|full|full,nosmt} to control the mitigation. Signed-off-by: Pawan Gupta Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner [cascardo: arch/x86/kvm/vmx.c has been moved] Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- Documentation/kernel-parameters.txt | 36 +++++++++++ arch/x86/include/asm/nospec-branch.h | 2=20 arch/x86/kernel/cpu/bugs.c | 111 ++++++++++++++++++++++++++++++= +++-- arch/x86/kvm/vmx.c | 3=20 4 files changed, 148 insertions(+), 4 deletions(-) --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2520,6 +2520,7 @@ bytes respectively. Such letter suffixes kvm.nx_huge_pages=3Doff [X86] no_entry_flush [PPC] no_uaccess_flush [PPC] + mmio_stale_data=3Doff [X86] =20 Exceptions: This does not have any effect on @@ -2541,6 +2542,7 @@ bytes respectively. Such letter suffixes Equivalent to: l1tf=3Dflush,nosmt [X86] mds=3Dfull,nosmt [X86] tsx_async_abort=3Dfull,nosmt [X86] + mmio_stale_data=3Dfull,nosmt [X86] =20 mminit_loglevel=3D [KNL] When CONFIG_DEBUG_MEMORY_INIT is set, this @@ -2550,6 +2552,40 @@ bytes respectively. Such letter suffixes log everything. Information is printed at KERN_DEBUG so loglevel=3D8 may also need to be specified. =20 + mmio_stale_data=3D + [X86,INTEL] Control mitigation for the Processor + MMIO Stale Data vulnerabilities. + + Processor MMIO Stale Data is a class of + vulnerabilities that may expose data after an MMIO + operation. Exposed data could originate or end in + the same CPU buffers as affected by MDS and TAA. + Therefore, similar to MDS and TAA, the mitigation + is to clear the affected CPU buffers. + + This parameter controls the mitigation. The + options are: + + full - Enable mitigation on vulnerable CPUs + + full,nosmt - Enable mitigation and disable SMT on + vulnerable CPUs. + + off - Unconditionally disable mitigation + + On MDS or TAA affected machines, + mmio_stale_data=3Doff can be prevented by an active + MDS or TAA mitigation as these vulnerabilities are + mitigated with the same mechanism so in order to + disable this mitigation, you need to specify + mds=3Doff and tsx_async_abort=3Doff too. + + Not specifying this option is equivalent to + mmio_stale_data=3Dfull. + + For details see: + Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst + module.sig_enforce [KNL] When CONFIG_MODULE_SIG is set, this means that modules without (valid) signatures will fail to load. --- a/arch/x86/include/asm/nospec-branch.h +++ b/arch/x86/include/asm/nospec-branch.h @@ -323,6 +323,8 @@ DECLARE_STATIC_KEY_FALSE(switch_mm_alway DECLARE_STATIC_KEY_FALSE(mds_user_clear); DECLARE_STATIC_KEY_FALSE(mds_idle_clear); =20 +DECLARE_STATIC_KEY_FALSE(mmio_stale_data_clear); + #include =20 /** --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -41,6 +41,7 @@ static void __init l1tf_select_mitigatio static void __init mds_select_mitigation(void); static void __init md_clear_update_mitigation(void); static void __init taa_select_mitigation(void); +static void __init mmio_select_mitigation(void); static void __init srbds_select_mitigation(void); =20 /* The base value of the SPEC_CTRL MSR that always has to be preserved. */ @@ -75,6 +76,10 @@ EXPORT_SYMBOL_GPL(mds_user_clear); DEFINE_STATIC_KEY_FALSE(mds_idle_clear); EXPORT_SYMBOL_GPL(mds_idle_clear); =20 +/* Controls CPU Fill buffer clear before KVM guest MMIO accesses */ +DEFINE_STATIC_KEY_FALSE(mmio_stale_data_clear); +EXPORT_SYMBOL_GPL(mmio_stale_data_clear); + void __init check_bugs(void) { identify_boot_cpu(); @@ -109,11 +114,13 @@ void __init check_bugs(void) l1tf_select_mitigation(); mds_select_mitigation(); taa_select_mitigation(); + mmio_select_mitigation(); srbds_select_mitigation(); =20 /* - * As MDS and TAA mitigations are inter-related, update and print their - * mitigation after TAA mitigation selection is done. + * As MDS, TAA and MMIO Stale Data mitigations are inter-related, update + * and print their mitigation after MDS, TAA and MMIO Stale Data + * mitigation selection is done. */ md_clear_update_mitigation(); =20 @@ -373,6 +380,90 @@ static int __init tsx_async_abort_parse_ early_param("tsx_async_abort", tsx_async_abort_parse_cmdline); =20 #undef pr_fmt +#define pr_fmt(fmt) "MMIO Stale Data: " fmt + +enum mmio_mitigations { + MMIO_MITIGATION_OFF, + MMIO_MITIGATION_UCODE_NEEDED, + MMIO_MITIGATION_VERW, +}; + +/* Default mitigation for Processor MMIO Stale Data vulnerabilities */ +static enum mmio_mitigations mmio_mitigation __ro_after_init =3D MMIO_MITI= GATION_VERW; +static bool mmio_nosmt __ro_after_init =3D false; + +static const char * const mmio_strings[] =3D { + [MMIO_MITIGATION_OFF] =3D "Vulnerable", + [MMIO_MITIGATION_UCODE_NEEDED] =3D "Vulnerable: Clear CPU buffers attempt= ed, no microcode", + [MMIO_MITIGATION_VERW] =3D "Mitigation: Clear CPU buffers", +}; + +static void __init mmio_select_mitigation(void) +{ + u64 ia32_cap; + + if (!boot_cpu_has_bug(X86_BUG_MMIO_STALE_DATA) || + cpu_mitigations_off()) { + mmio_mitigation =3D MMIO_MITIGATION_OFF; + return; + } + + if (mmio_mitigation =3D=3D MMIO_MITIGATION_OFF) + return; + + ia32_cap =3D x86_read_arch_cap_msr(); + + /* + * Enable CPU buffer clear mitigation for host and VMM, if also affected + * by MDS or TAA. Otherwise, enable mitigation for VMM only. + */ + if (boot_cpu_has_bug(X86_BUG_MDS) || (boot_cpu_has_bug(X86_BUG_TAA) && + boot_cpu_has(X86_FEATURE_RTM))) + static_branch_enable(&mds_user_clear); + else + static_branch_enable(&mmio_stale_data_clear); + + /* + * Check if the system has the right microcode. + * + * CPU Fill buffer clear mitigation is enumerated by either an explicit + * FB_CLEAR or by the presence of both MD_CLEAR and L1D_FLUSH on MDS + * affected systems. + */ + if ((ia32_cap & ARCH_CAP_FB_CLEAR) || + (boot_cpu_has(X86_FEATURE_MD_CLEAR) && + boot_cpu_has(X86_FEATURE_FLUSH_L1D) && + !(ia32_cap & ARCH_CAP_MDS_NO))) + mmio_mitigation =3D MMIO_MITIGATION_VERW; + else + mmio_mitigation =3D MMIO_MITIGATION_UCODE_NEEDED; + + if (mmio_nosmt || cpu_mitigations_auto_nosmt()) + cpu_smt_disable(false); +} + +static int __init mmio_stale_data_parse_cmdline(char *str) +{ + if (!boot_cpu_has_bug(X86_BUG_MMIO_STALE_DATA)) + return 0; + + if (!str) + return -EINVAL; + + if (!strcmp(str, "off")) { + mmio_mitigation =3D MMIO_MITIGATION_OFF; + } else if (!strcmp(str, "full")) { + mmio_mitigation =3D MMIO_MITIGATION_VERW; + } else if (!strcmp(str, "full,nosmt")) { + mmio_mitigation =3D MMIO_MITIGATION_VERW; + mmio_nosmt =3D true; + } + + return 0; +} +early_param("mmio_stale_data", mmio_stale_data_parse_cmdline); + +#undef pr_fmt #define pr_fmt(fmt) "" fmt =20 static void __init md_clear_update_mitigation(void) @@ -384,19 +475,31 @@ static void __init md_clear_update_mitig goto out; =20 /* - * mds_user_clear is now enabled. Update MDS mitigation, if - * necessary. + * mds_user_clear is now enabled. Update MDS, TAA and MMIO Stale Data + * mitigation, if necessary. */ if (mds_mitigation =3D=3D MDS_MITIGATION_OFF && boot_cpu_has_bug(X86_BUG_MDS)) { mds_mitigation =3D MDS_MITIGATION_FULL; mds_select_mitigation(); } + if (taa_mitigation =3D=3D TAA_MITIGATION_OFF && + boot_cpu_has_bug(X86_BUG_TAA)) { + taa_mitigation =3D TAA_MITIGATION_VERW; + taa_select_mitigation(); + } + if (mmio_mitigation =3D=3D MMIO_MITIGATION_OFF && + boot_cpu_has_bug(X86_BUG_MMIO_STALE_DATA)) { + mmio_mitigation =3D MMIO_MITIGATION_VERW; + mmio_select_mitigation(); + } out: if (boot_cpu_has_bug(X86_BUG_MDS)) pr_info("MDS: %s\n", mds_strings[mds_mitigation]); if (boot_cpu_has_bug(X86_BUG_TAA)) pr_info("TAA: %s\n", taa_strings[taa_mitigation]); + if (boot_cpu_has_bug(X86_BUG_MMIO_STALE_DATA)) + pr_info("MMIO Stale Data: %s\n", mmio_strings[mmio_mitigation]); } =20 #undef pr_fmt --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -9177,6 +9177,9 @@ static void __noclone vmx_vcpu_run(struc vmx_l1d_flush(vcpu); else if (static_branch_unlikely(&mds_user_clear)) mds_clear_cpu_buffers(); + else if (static_branch_unlikely(&mmio_stale_data_clear) && + kvm_arch_has_assigned_device(vcpu->kvm)) + mds_clear_cpu_buffers(); =20 asm( /* Store host registers */ From nobody Mon Apr 27 10:04:57 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 79552C433EF for ; Tue, 14 Jun 2022 18:41:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1354137AbiFNSl2 (ORCPT ); Tue, 14 Jun 2022 14:41:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58108 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1356086AbiFNSlR (ORCPT ); Tue, 14 Jun 2022 14:41:17 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 091AA49CAF; Tue, 14 Jun 2022 11:41:15 -0700 (PDT) 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 B06D0B81AF2; Tue, 14 Jun 2022 18:41:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0FFC6C3411B; Tue, 14 Jun 2022 18:41:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1655232072; bh=AD6M8R0F9Ak/do8OFvGwfHxyqKd6t20kvQOZOhgHRDY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VazhfC3JdblE++yuGDSB8fEc31ULBAo7fZzRjh2zx2/cjZOXOruZyMRyoJ5qpo36+ NT5bB+dBjgGjnq7UmGfnhJ2MlUwEYZBff/hS3ByGuDyB7LNWz/4rb4Omid+VUyFm71 0IObRPQ45p0P5KWGeEHD5VjzHAL2McIT+2gFbrK0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Pawan Gupta , Borislav Petkov , Thomas Gleixner , Thadeu Lima de Souza Cascardo Subject: [PATCH 4.9 14/20] x86/bugs: Group MDS, TAA & Processor MMIO Stale Data mitigations Date: Tue, 14 Jun 2022 20:39:57 +0200 Message-Id: <20220614183725.465157330@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220614183722.061550591@linuxfoundation.org> References: <20220614183722.061550591@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Pawan Gupta commit e5925fb867290ee924fcf2fe3ca887b792714366 upstream MDS, TAA and Processor MMIO Stale Data mitigations rely on clearing CPU buffers. Moreover, status of these mitigations affects each other. During boot, it is important to maintain the order in which these mitigations are selected. This is especially true for md_clear_update_mitigation() that needs to be called after MDS, TAA and Processor MMIO Stale Data mitigation selection is done. Introduce md_clear_select_mitigation(), and select all these mitigations from there. This reflects relationships between these mitigations and ensures proper ordering. Signed-off-by: Pawan Gupta Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/x86/kernel/cpu/bugs.c | 26 ++++++++++++++++---------- 1 file changed, 16 insertions(+), 10 deletions(-) --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -40,6 +40,7 @@ static void __init ssb_select_mitigation static void __init l1tf_select_mitigation(void); static void __init mds_select_mitigation(void); static void __init md_clear_update_mitigation(void); +static void __init md_clear_select_mitigation(void); static void __init taa_select_mitigation(void); static void __init mmio_select_mitigation(void); static void __init srbds_select_mitigation(void); @@ -112,18 +113,9 @@ void __init check_bugs(void) spectre_v2_select_mitigation(); ssb_select_mitigation(); l1tf_select_mitigation(); - mds_select_mitigation(); - taa_select_mitigation(); - mmio_select_mitigation(); + md_clear_select_mitigation(); srbds_select_mitigation(); =20 - /* - * As MDS, TAA and MMIO Stale Data mitigations are inter-related, update - * and print their mitigation after MDS, TAA and MMIO Stale Data - * mitigation selection is done. - */ - md_clear_update_mitigation(); - arch_smt_update(); =20 #ifdef CONFIG_X86_32 @@ -502,6 +494,20 @@ out: pr_info("MMIO Stale Data: %s\n", mmio_strings[mmio_mitigation]); } =20 +static void __init md_clear_select_mitigation(void) +{ + mds_select_mitigation(); + taa_select_mitigation(); + mmio_select_mitigation(); + + /* + * As MDS, TAA and MMIO Stale Data mitigations are inter-related, update + * and print their mitigation after MDS, TAA and MMIO Stale Data + * mitigation selection is done. + */ + md_clear_update_mitigation(); +} + #undef pr_fmt #define pr_fmt(fmt) "SRBDS: " fmt From nobody Mon Apr 27 10:04:57 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C30C7C43334 for ; Tue, 14 Jun 2022 18:41:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345403AbiFNSll (ORCPT ); Tue, 14 Jun 2022 14:41:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58118 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1356426AbiFNSlS (ORCPT ); Tue, 14 Jun 2022 14:41:18 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6DD054969A; Tue, 14 Jun 2022 11:41:16 -0700 (PDT) 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 dfw.source.kernel.org (Postfix) with ESMTPS id DD414617C2; Tue, 14 Jun 2022 18:41:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E3B55C3411B; Tue, 14 Jun 2022 18:41:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1655232075; bh=+PS1FasQL1d9Ko84VEhMcUiqKJHZX1Lc9ZLC323IQNw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=iCPw61Ufk2mlJwOaGufwWL/lSuuIJzUOqcETeDEQmzLDv1bobLcdt2HVepQmqVD5p WpcqjBbGtbQjn3D9VOqEVG9Fna91SKz392o5Es7EP21D/phfZ8VgHO4blNwu9snvjk gTLvhIj6gmiHQiClaQtUFSzvJeiDi6vOedQQlYPw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Pawan Gupta , Thomas Gleixner , Josh Poimboeuf , Borislav Petkov , Thadeu Lima de Souza Cascardo Subject: [PATCH 4.9 15/20] x86/speculation/mmio: Enable CPU Fill buffer clearing on idle Date: Tue, 14 Jun 2022 20:39:58 +0200 Message-Id: <20220614183725.698486215@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220614183722.061550591@linuxfoundation.org> References: <20220614183722.061550591@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Pawan Gupta commit 99a83db5a605137424e1efe29dc0573d6a5b6316 upstream When the CPU is affected by Processor MMIO Stale Data vulnerabilities, Fill Buffer Stale Data Propagator (FBSDP) can propagate stale data out of Fill buffer to uncore buffer when CPU goes idle. Stale data can then be exploited with other variants using MMIO operations. Mitigate it by clearing the Fill buffer before entering idle state. Signed-off-by: Pawan Gupta Signed-off-by: Thomas Gleixner Co-developed-by: Josh Poimboeuf Signed-off-by: Josh Poimboeuf Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/x86/kernel/cpu/bugs.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -416,6 +416,14 @@ static void __init mmio_select_mitigatio static_branch_enable(&mmio_stale_data_clear); =20 /* + * If Processor-MMIO-Stale-Data bug is present and Fill Buffer data can + * be propagated to uncore buffers, clearing the Fill buffers on idle + * is required irrespective of SMT state. + */ + if (!(ia32_cap & ARCH_CAP_FBSDP_NO)) + static_branch_enable(&mds_idle_clear); + + /* * Check if the system has the right microcode. * * CPU Fill buffer clear mitigation is enumerated by either an explicit @@ -1181,6 +1189,8 @@ static void update_indir_branch_cond(voi /* Update the static key controlling the MDS CPU buffer clear in idle */ static void update_mds_branch_idle(void) { + u64 ia32_cap =3D x86_read_arch_cap_msr(); + /* * Enable the idle clearing if SMT is active on CPUs which are * affected only by MSBDS and not any other MDS variant. @@ -1192,10 +1202,12 @@ static void update_mds_branch_idle(void) if (!boot_cpu_has_bug(X86_BUG_MSBDS_ONLY)) return; =20 - if (sched_smt_active()) + if (sched_smt_active()) { static_branch_enable(&mds_idle_clear); - else + } else if (mmio_mitigation =3D=3D MMIO_MITIGATION_OFF || + (ia32_cap & ARCH_CAP_FBSDP_NO)) { static_branch_disable(&mds_idle_clear); + } } =20 #define MDS_MSG_SMT "MDS CPU bug present and SMT on, data leak possible. S= ee https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for = more details.\n" From nobody Mon Apr 27 10:04:57 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1F212CCA47A for ; Tue, 14 Jun 2022 18:41:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357114AbiFNSlv (ORCPT ); Tue, 14 Jun 2022 14:41:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58118 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1356667AbiFNSlY (ORCPT ); Tue, 14 Jun 2022 14:41:24 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DADCE49931; Tue, 14 Jun 2022 11:41:20 -0700 (PDT) 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 89D58B81AEF; Tue, 14 Jun 2022 18:41:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DCB18C3411B; Tue, 14 Jun 2022 18:41:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1655232078; bh=UmU3JoSkg88coxgK7WiDNTTgKhSETF29YA42o0WaihU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VJzB2MLrg4bm6S3yB21JURHsFpTpJoDJTTVBII4vVFkafYS/1cmAKXjEJ9grTnCBv tz/K0O9xIAYiCj1pH8vwEgs3k/4PsvJ93eBF1km66Me4glBW7FDq2AvFPYESBrSB0F OZM++IbKDypu2vB1rzZ4kVV46NcNcyTNMmH7l3UE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Pawan Gupta , Borislav Petkov , Thomas Gleixner , Thadeu Lima de Souza Cascardo Subject: [PATCH 4.9 16/20] x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data Date: Tue, 14 Jun 2022 20:39:59 +0200 Message-Id: <20220614183725.921690236@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220614183722.061550591@linuxfoundation.org> References: <20220614183722.061550591@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Pawan Gupta commit 8d50cdf8b8341770bc6367bce40c0c1bb0e1d5b3 upstream Add the sysfs reporting file for Processor MMIO Stale Data vulnerability. It exposes the vulnerability and mitigation state similar to the existing files for the other hardware vulnerabilities. Signed-off-by: Pawan Gupta Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- Documentation/ABI/testing/sysfs-devices-system-cpu | 1=20 arch/x86/kernel/cpu/bugs.c | 22 ++++++++++++++++= +++++ drivers/base/cpu.c | 8 +++++++ include/linux/cpu.h | 3 ++ 4 files changed, 34 insertions(+) --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -361,6 +361,7 @@ What: /sys/devices/system/cpu/vulnerabi /sys/devices/system/cpu/vulnerabilities/srbds /sys/devices/system/cpu/vulnerabilities/tsx_async_abort /sys/devices/system/cpu/vulnerabilities/itlb_multihit + /sys/devices/system/cpu/vulnerabilities/mmio_stale_data Date: January 2018 Contact: Linux kernel mailing list Description: Information about CPU vulnerabilities --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -1809,6 +1809,20 @@ static ssize_t tsx_async_abort_show_stat sched_smt_active() ? "vulnerable" : "disabled"); } =20 +static ssize_t mmio_stale_data_show_state(char *buf) +{ + if (mmio_mitigation =3D=3D MMIO_MITIGATION_OFF) + return sysfs_emit(buf, "%s\n", mmio_strings[mmio_mitigation]); + + if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) { + return sysfs_emit(buf, "%s; SMT Host state unknown\n", + mmio_strings[mmio_mitigation]); + } + + return sysfs_emit(buf, "%s; SMT %s\n", mmio_strings[mmio_mitigation], + sched_smt_active() ? "vulnerable" : "disabled"); +} + static char *stibp_state(void) { if (spectre_v2_in_eibrs_mode(spectre_v2_enabled)) @@ -1906,6 +1920,9 @@ static ssize_t cpu_show_common(struct de case X86_BUG_SRBDS: return srbds_show_state(buf); =20 + case X86_BUG_MMIO_STALE_DATA: + return mmio_stale_data_show_state(buf); + default: break; } @@ -1957,4 +1974,9 @@ ssize_t cpu_show_srbds(struct device *de { return cpu_show_common(dev, attr, buf, X86_BUG_SRBDS); } + +ssize_t cpu_show_mmio_stale_data(struct device *dev, struct device_attribu= te *attr, char *buf) +{ + return cpu_show_common(dev, attr, buf, X86_BUG_MMIO_STALE_DATA); +} #endif --- a/drivers/base/cpu.c +++ b/drivers/base/cpu.c @@ -556,6 +556,12 @@ ssize_t __weak cpu_show_srbds(struct dev return sprintf(buf, "Not affected\n"); } =20 +ssize_t __weak cpu_show_mmio_stale_data(struct device *dev, + struct device_attribute *attr, char *buf) +{ + return sysfs_emit(buf, "Not affected\n"); +} + static DEVICE_ATTR(meltdown, 0444, cpu_show_meltdown, NULL); static DEVICE_ATTR(spectre_v1, 0444, cpu_show_spectre_v1, NULL); static DEVICE_ATTR(spectre_v2, 0444, cpu_show_spectre_v2, NULL); @@ -565,6 +571,7 @@ static DEVICE_ATTR(mds, 0444, cpu_show_m static DEVICE_ATTR(tsx_async_abort, 0444, cpu_show_tsx_async_abort, NULL); static DEVICE_ATTR(itlb_multihit, 0444, cpu_show_itlb_multihit, NULL); static DEVICE_ATTR(srbds, 0444, cpu_show_srbds, NULL); +static DEVICE_ATTR(mmio_stale_data, 0444, cpu_show_mmio_stale_data, NULL); =20 static struct attribute *cpu_root_vulnerabilities_attrs[] =3D { &dev_attr_meltdown.attr, @@ -576,6 +583,7 @@ static struct attribute *cpu_root_vulner &dev_attr_tsx_async_abort.attr, &dev_attr_itlb_multihit.attr, &dev_attr_srbds.attr, + &dev_attr_mmio_stale_data.attr, NULL }; =20 --- a/include/linux/cpu.h +++ b/include/linux/cpu.h @@ -62,6 +62,9 @@ extern ssize_t cpu_show_tsx_async_abort( extern ssize_t cpu_show_itlb_multihit(struct device *dev, struct device_attribute *attr, char *buf); extern ssize_t cpu_show_srbds(struct device *dev, struct device_attribute = *attr, char *buf); +extern ssize_t cpu_show_mmio_stale_data(struct device *dev, + struct device_attribute *attr, + char *buf); =20 extern __printf(4, 5) struct device *cpu_device_create(struct device *parent, void *drvdata, From nobody Mon Apr 27 10:04:57 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 09F19C43334 for ; Tue, 14 Jun 2022 18:41:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357020AbiFNSlz (ORCPT ); Tue, 14 Jun 2022 14:41:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58458 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1356711AbiFNSlZ (ORCPT ); Tue, 14 Jun 2022 14:41:25 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F167A49909; Tue, 14 Jun 2022 11:41:21 -0700 (PDT) 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 dfw.source.kernel.org (Postfix) with ESMTPS id 8E6C4617C2; Tue, 14 Jun 2022 18:41:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9A891C3411D; Tue, 14 Jun 2022 18:41:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1655232081; bh=o8lUshtwV6A8yIw598SaYBt6OQxFa+3oR479FU/UOwk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=zTt7qmfZ1scSr58nLDrCOiovxV1N2kqAPNDSKWRzHh/xyA0kYme1xrtPs3fYZeuR1 6r4F+fqOSNdFeXXGvb9RWuL61WxwjoXwtaogpOuNq5q1JJAsKZ5wna6HjwCmg9BQ+N qW+WdYHTC0oTsNUQ65CcZgzlmEAJHjuimhqAGV+w= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Pawan Gupta , Borislav Petkov , Thomas Gleixner , Thadeu Lima de Souza Cascardo Subject: [PATCH 4.9 17/20] x86/speculation/srbds: Update SRBDS mitigation selection Date: Tue, 14 Jun 2022 20:40:00 +0200 Message-Id: <20220614183726.151810525@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220614183722.061550591@linuxfoundation.org> References: <20220614183722.061550591@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Pawan Gupta commit 22cac9c677c95f3ac5c9244f8ca0afdc7c8afb19 upstream Currently, Linux disables SRBDS mitigation on CPUs not affected by MDS and have the TSX feature disabled. On such CPUs, secrets cannot be extracted from CPU fill buffers using MDS or TAA. Without SRBDS mitigation, Processor MMIO Stale Data vulnerabilities can be used to extract RDRAND, RDSEED, and EGETKEY data. Do not disable SRBDS mitigation by default when CPU is also affected by Processor MMIO Stale Data vulnerabilities. Signed-off-by: Pawan Gupta Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/x86/kernel/cpu/bugs.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -577,11 +577,13 @@ static void __init srbds_select_mitigati return; =20 /* - * Check to see if this is one of the MDS_NO systems supporting - * TSX that are only exposed to SRBDS when TSX is enabled. + * Check to see if this is one of the MDS_NO systems supporting TSX that + * are only exposed to SRBDS when TSX is enabled or when CPU is affected + * by Processor MMIO Stale Data vulnerability. */ ia32_cap =3D x86_read_arch_cap_msr(); - if ((ia32_cap & ARCH_CAP_MDS_NO) && !boot_cpu_has(X86_FEATURE_RTM)) + if ((ia32_cap & ARCH_CAP_MDS_NO) && !boot_cpu_has(X86_FEATURE_RTM) && + !boot_cpu_has_bug(X86_BUG_MMIO_STALE_DATA)) srbds_mitigation =3D SRBDS_MITIGATION_TSX_OFF; else if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) srbds_mitigation =3D SRBDS_MITIGATION_HYPERVISOR; From nobody Mon Apr 27 10:04:57 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7C167C433EF for ; Tue, 14 Jun 2022 18:42:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1356982AbiFNSl7 (ORCPT ); Tue, 14 Jun 2022 14:41:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58174 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1356876AbiFNSlb (ORCPT ); Tue, 14 Jun 2022 14:41:31 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1769149F2E; Tue, 14 Jun 2022 11:41:25 -0700 (PDT) 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 dfw.source.kernel.org (Postfix) with ESMTPS id 52172617C1; Tue, 14 Jun 2022 18:41:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5B02EC3411B; Tue, 14 Jun 2022 18:41:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1655232083; bh=4QIHLAGFhjL/KiLp1O3/nEyF85lPAfW056oCA8WF/YQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=broF6pat2E3/X9987WU8eoHWqzrKI9kgaMbDvacjZrGdg7m/nVycQwXZdlvDISjAW NoNmM//b+8tvBiWKH6uVYwlV6cls4oZIrJRZJ1Qw8mo4H5T9DoGc90kcC1L0S8cUTY 8k/Ib+9ealBqfTmnkIVZjJ0NbvFVlWmhQjrYeVBg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Pawan Gupta , Borislav Petkov , Thomas Gleixner , Thadeu Lima de Souza Cascardo Subject: [PATCH 4.9 18/20] x86/speculation/mmio: Reuse SRBDS mitigation for SBDS Date: Tue, 14 Jun 2022 20:40:01 +0200 Message-Id: <20220614183726.418477518@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220614183722.061550591@linuxfoundation.org> References: <20220614183722.061550591@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Pawan Gupta commit a992b8a4682f119ae035a01b40d4d0665c4a2875 upstream The Shared Buffers Data Sampling (SBDS) variant of Processor MMIO Stale Data vulnerabilities may expose RDRAND, RDSEED and SGX EGETKEY data. Mitigation for this is added by a microcode update. As some of the implications of SBDS are similar to SRBDS, SRBDS mitigation infrastructure can be leveraged by SBDS. Set X86_BUG_SRBDS and use SRBDS mitigation. Mitigation is enabled by default; use srbds=3Doff to opt-out. Mitigation status can be checked from below file: /sys/devices/system/cpu/vulnerabilities/srbds Signed-off-by: Pawan Gupta Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner [cascardo: adjust for processor model names] Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/x86/kernel/cpu/common.c | 21 ++++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-) --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -964,6 +964,8 @@ static const __initconst struct x86_cpu_ #define SRBDS BIT(0) /* CPU is affected by X86_BUG_MMIO_STALE_DATA */ #define MMIO BIT(1) +/* CPU is affected by Shared Buffers Data Sampling (SBDS), a variant of X8= 6_BUG_MMIO_STALE_DATA */ +#define MMIO_SBDS BIT(2) =20 static const struct x86_cpu_id cpu_vuln_blacklist[] __initconst =3D { VULNBL_INTEL_STEPPINGS(IVYBRIDGE, X86_STEPPING_ANY, SRBDS), @@ -985,16 +987,17 @@ static const struct x86_cpu_id cpu_vuln_ VULNBL_INTEL_STEPPINGS(KABYLAKE_MOBILE, X86_STEPPINGS(0x0, 0x8), SRBDS), VULNBL_INTEL_STEPPINGS(KABYLAKE_DESKTOP,X86_STEPPINGS(0x9, 0xD), SRBDS | = MMIO), VULNBL_INTEL_STEPPINGS(KABYLAKE_DESKTOP,X86_STEPPINGS(0x0, 0x8), SRBDS), - VULNBL_INTEL_STEPPINGS(ICELAKE_MOBILE, X86_STEPPINGS(0x5, 0x5), MMIO), + VULNBL_INTEL_STEPPINGS(ICELAKE_MOBILE, X86_STEPPINGS(0x5, 0x5), MMIO | MM= IO_SBDS), VULNBL_INTEL_STEPPINGS(ICELAKE_XEON_D, X86_STEPPINGS(0x1, 0x1), MMIO), VULNBL_INTEL_STEPPINGS(ICELAKE_X, X86_STEPPINGS(0x4, 0x6), MMIO), - VULNBL_INTEL_STEPPINGS(COMETLAKE, BIT(2) | BIT(3) | BIT(5), MMIO), - VULNBL_INTEL_STEPPINGS(COMETLAKE_L, X86_STEPPINGS(0x0, 0x1), MMIO), - VULNBL_INTEL_STEPPINGS(LAKEFIELD, X86_STEPPINGS(0x1, 0x1), MMIO), + VULNBL_INTEL_STEPPINGS(COMETLAKE, BIT(2) | BIT(3) | BIT(5), MMIO | MMIO_S= BDS), + VULNBL_INTEL_STEPPINGS(COMETLAKE_L, X86_STEPPINGS(0x1, 0x1), MMIO | MMIO_= SBDS), + VULNBL_INTEL_STEPPINGS(COMETLAKE_L, X86_STEPPINGS(0x0, 0x0), MMIO), + VULNBL_INTEL_STEPPINGS(LAKEFIELD, X86_STEPPINGS(0x1, 0x1), MMIO | MMIO_SB= DS), VULNBL_INTEL_STEPPINGS(ROCKETLAKE, X86_STEPPINGS(0x1, 0x1), MMIO), - VULNBL_INTEL_STEPPINGS(ATOM_TREMONT, X86_STEPPINGS(0x1, 0x1), MMIO), + VULNBL_INTEL_STEPPINGS(ATOM_TREMONT, X86_STEPPINGS(0x1, 0x1), MMIO | MMIO= _SBDS), VULNBL_INTEL_STEPPINGS(ATOM_TREMONT_X, X86_STEPPING_ANY, MMIO), - VULNBL_INTEL_STEPPINGS(ATOM_TREMONT_L, X86_STEPPINGS(0x0, 0x0), MMIO), + VULNBL_INTEL_STEPPINGS(ATOM_TREMONT_L, X86_STEPPINGS(0x0, 0x0), MMIO | MM= IO_SBDS), {} }; =20 @@ -1073,10 +1076,14 @@ static void __init cpu_set_bug_bits(stru /* * SRBDS affects CPUs which support RDRAND or RDSEED and are listed * in the vulnerability blacklist. + * + * Some of the implications and mitigation of Shared Buffers Data + * Sampling (SBDS) are similar to SRBDS. Give SBDS same treatment as + * SRBDS. */ if ((cpu_has(c, X86_FEATURE_RDRAND) || cpu_has(c, X86_FEATURE_RDSEED)) && - cpu_matches(cpu_vuln_blacklist, SRBDS)) + cpu_matches(cpu_vuln_blacklist, SRBDS | MMIO_SBDS)) setup_force_cpu_bug(X86_BUG_SRBDS); =20 /* From nobody Mon Apr 27 10:04:57 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C9B1EC433EF for ; Tue, 14 Jun 2022 18:42:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357036AbiFNSmE (ORCPT ); Tue, 14 Jun 2022 14:42:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58458 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357018AbiFNSlr (ORCPT ); Tue, 14 Jun 2022 14:41:47 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4A2B84A3CC; Tue, 14 Jun 2022 11:41:29 -0700 (PDT) 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 C09A3B81AEC; Tue, 14 Jun 2022 18:41:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 23BE6C3411B; Tue, 14 Jun 2022 18:41:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1655232086; bh=K9p3iUAsohSO/4Fdefx78Pou5Zu4QtY9SVApjihZBoQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Zq/9ROeqd3CXNwqP/FEeflbOjpAgMo6jLiBCznVlzB1tYK9sMYk680xxWA70lVuHt avZ4setIsx2YdYji7cb+lNLmj8m6jUEZDh1mAT+LqQyhuW8u/o/7UfZZ9bk6Maf8TK a84dA0T79p0aGe2Oz+TwLavAAFj5IEsX8WmgjMFU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Pawan Gupta , Borislav Petkov , Thomas Gleixner , Thadeu Lima de Souza Cascardo Subject: [PATCH 4.9 19/20] KVM: x86/speculation: Disable Fill buffer clear within guests Date: Tue, 14 Jun 2022 20:40:02 +0200 Message-Id: <20220614183726.651750093@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220614183722.061550591@linuxfoundation.org> References: <20220614183722.061550591@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Pawan Gupta commit 027bbb884be006b05d9c577d6401686053aa789e upstream The enumeration of MD_CLEAR in CPUID(EAX=3D7,ECX=3D0).EDX{bit 10} is not an accurate indicator on all CPUs of whether the VERW instruction will overwrite fill buffers. FB_CLEAR enumeration in IA32_ARCH_CAPABILITIES{bit 17} covers the case of CPUs that are not vulnerable to MDS/TAA, indicating that microcode does overwrite fill buffers. Guests running in VMM environments may not be aware of all the capabilities/vulnerabilities of the host CPU. Specifically, a guest may apply MDS/TAA mitigations when a virtual CPU is enumerated as vulnerable to MDS/TAA even when the physical CPU is not. On CPUs that enumerate FB_CLEAR_CTRL the VMM may set FB_CLEAR_DIS to skip overwriting of fill buffers by the VERW instruction. This is done by setting FB_CLEAR_DIS during VMENTER and resetting on VMEXIT. For guests that enumerate FB_CLEAR (explicitly asking for fill buffer clear capability) the VMM will not use FB_CLEAR_DIS. Irrespective of guest state, host overwrites CPU buffers before VMENTER to protect itself from an MMIO capable guest, as part of mitigation for MMIO Stale Data vulnerabilities. Signed-off-by: Pawan Gupta Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner [cascardo: arch/x86/kvm/vmx.c has been split and context adjustment at vmx_vcpu_run] [cascardo: moved functions so they are after struct vcpu_vmx definition] [cascardo: fb_clear is disabled/enabled around __vmx_vcpu_run] [cascardo: conflict context fixups] Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/x86/include/asm/msr-index.h | 6 +++ arch/x86/kvm/vmx.c | 74 ++++++++++++++++++++++++++++++++++= ++++- arch/x86/kvm/x86.c | 4 ++ 3 files changed, 83 insertions(+), 1 deletion(-) --- a/arch/x86/include/asm/msr-index.h +++ b/arch/x86/include/asm/msr-index.h @@ -108,6 +108,11 @@ * VERW clears CPU fill buffer * even on MDS_NO CPUs. */ +#define ARCH_CAP_FB_CLEAR_CTRL BIT(18) /* + * MSR_IA32_MCU_OPT_CTRL[FB_CLEAR_DIS] + * bit available to control VERW + * behavior. + */ =20 #define MSR_IA32_FLUSH_CMD 0x0000010b #define L1D_FLUSH BIT(0) /* @@ -125,6 +130,7 @@ /* SRBDS support */ #define MSR_IA32_MCU_OPT_CTRL 0x00000123 #define RNGDS_MITG_DIS BIT(0) +#define FB_CLEAR_DIS BIT(3) /* CPU Fill buffer clear disable */ =20 #define MSR_IA32_SYSENTER_CS 0x00000174 #define MSR_IA32_SYSENTER_ESP 0x00000175 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -211,6 +211,9 @@ static const struct { #define L1D_CACHE_ORDER 4 static void *vmx_l1d_flush_pages; =20 +/* Control for disabling CPU Fill buffer clear */ +static bool __read_mostly vmx_fb_clear_ctrl_available; + static int vmx_setup_l1d_flush(enum vmx_l1d_flush_state l1tf) { struct page *page; @@ -794,6 +797,8 @@ struct vcpu_vmx { */ u64 msr_ia32_feature_control; u64 msr_ia32_feature_control_valid_bits; + u64 msr_ia32_mcu_opt_ctrl; + bool disable_fb_clear; }; =20 enum segment_cache_field { @@ -1573,6 +1578,60 @@ static inline void __invept(unsigned lon : : "a" (&operand), "c" (ext) : "cc", "memory"); } =20 +static void vmx_setup_fb_clear_ctrl(void) +{ + u64 msr; + + if (boot_cpu_has(X86_FEATURE_ARCH_CAPABILITIES) && + !boot_cpu_has_bug(X86_BUG_MDS) && + !boot_cpu_has_bug(X86_BUG_TAA)) { + rdmsrl(MSR_IA32_ARCH_CAPABILITIES, msr); + if (msr & ARCH_CAP_FB_CLEAR_CTRL) + vmx_fb_clear_ctrl_available =3D true; + } +} + +static __always_inline void vmx_disable_fb_clear(struct vcpu_vmx *vmx) +{ + u64 msr; + + if (!vmx->disable_fb_clear) + return; + + rdmsrl(MSR_IA32_MCU_OPT_CTRL, msr); + msr |=3D FB_CLEAR_DIS; + wrmsrl(MSR_IA32_MCU_OPT_CTRL, msr); + /* Cache the MSR value to avoid reading it later */ + vmx->msr_ia32_mcu_opt_ctrl =3D msr; +} + +static __always_inline void vmx_enable_fb_clear(struct vcpu_vmx *vmx) +{ + if (!vmx->disable_fb_clear) + return; + + vmx->msr_ia32_mcu_opt_ctrl &=3D ~FB_CLEAR_DIS; + wrmsrl(MSR_IA32_MCU_OPT_CTRL, vmx->msr_ia32_mcu_opt_ctrl); +} + +static void vmx_update_fb_clear_dis(struct kvm_vcpu *vcpu, struct vcpu_vmx= *vmx) +{ + vmx->disable_fb_clear =3D vmx_fb_clear_ctrl_available; + + /* + * If guest will not execute VERW, there is no need to set FB_CLEAR_DIS + * at VMEntry. Skip the MSR read/write when a guest has no use case to + * execute VERW. + */ + if ((vcpu->arch.arch_capabilities & ARCH_CAP_FB_CLEAR) || + ((vcpu->arch.arch_capabilities & ARCH_CAP_MDS_NO) && + (vcpu->arch.arch_capabilities & ARCH_CAP_TAA_NO) && + (vcpu->arch.arch_capabilities & ARCH_CAP_PSDP_NO) && + (vcpu->arch.arch_capabilities & ARCH_CAP_FBSDP_NO) && + (vcpu->arch.arch_capabilities & ARCH_CAP_SBDR_SSDP_NO))) + vmx->disable_fb_clear =3D false; +} + static struct shared_msr_entry *find_msr_entry(struct vcpu_vmx *vmx, u32 m= sr) { int i; @@ -3407,9 +3466,13 @@ static int vmx_set_msr(struct kvm_vcpu * } break; } - ret =3D kvm_set_msr_common(vcpu, msr_info); + ret =3D kvm_set_msr_common(vcpu, msr_info); } =20 + /* FB_CLEAR may have changed, also update the FB_CLEAR_DIS behavior */ + if (msr_index =3D=3D MSR_IA32_ARCH_CAPABILITIES) + vmx_update_fb_clear_dis(vcpu, vmx); + return ret; } =20 @@ -5544,6 +5607,8 @@ static void vmx_vcpu_reset(struct kvm_vc update_exception_bitmap(vcpu); =20 vpid_sync_context(vmx->vpid); + + vmx_update_fb_clear_dis(vcpu, vmx); } =20 /* @@ -9181,6 +9246,8 @@ static void __noclone vmx_vcpu_run(struc kvm_arch_has_assigned_device(vcpu->kvm)) mds_clear_cpu_buffers(); =20 + vmx_disable_fb_clear(vmx); + asm( /* Store host registers */ "push %%" _ASM_DX "; push %%" _ASM_BP ";" @@ -9298,6 +9365,8 @@ static void __noclone vmx_vcpu_run(struc #endif ); =20 + vmx_enable_fb_clear(vmx); + /* * We do not use IBRS in the kernel. If this vCPU has used the * SPEC_CTRL MSR it may have left it on; save the value and @@ -11882,8 +11951,11 @@ static int __init vmx_init(void) } } =20 + vmx_setup_fb_clear_ctrl(); + for_each_possible_cpu(cpu) { INIT_LIST_HEAD(&per_cpu(loaded_vmcss_on_cpu, cpu)); + INIT_LIST_HEAD(&per_cpu(blocked_vcpu_on_cpu, cpu)); spin_lock_init(&per_cpu(blocked_vcpu_on_cpu_lock, cpu)); } --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -1090,6 +1090,10 @@ u64 kvm_get_arch_capabilities(void) =20 /* KVM does not emulate MSR_IA32_TSX_CTRL. */ data &=3D ~ARCH_CAP_TSX_CTRL_MSR; + + /* Guests don't need to know "Fill buffer clear control" exists */ + data &=3D ~ARCH_CAP_FB_CLEAR_CTRL; + return data; } From nobody Mon Apr 27 10:04:57 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0ADF1C43334 for ; Tue, 14 Jun 2022 18:42:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357157AbiFNSmP (ORCPT ); Tue, 14 Jun 2022 14:42:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59282 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357039AbiFNSls (ORCPT ); Tue, 14 Jun 2022 14:41:48 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2F1F24A90D; Tue, 14 Jun 2022 11:41:32 -0700 (PDT) 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 BC6B9B8186A; Tue, 14 Jun 2022 18:41:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DE315C3411B; Tue, 14 Jun 2022 18:41:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1655232089; bh=xwd8s0NcWWmmlf0T2SyWUX1VuDno50o8PJA1UhCikjg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AzM1SqU4RQvNFLL2ebRzg6mdy2eEcLIDP+3RDcfUVkSxn84U7/ILcruNqtvLX7dtp EGvJdkMKjQrrE7NhSRs7WBcaDJKbsEFrVgeJQuYB18fc6F3ZaW2Cnrtj6rhKf9H0Ke bxVuL68vTyRbbMwwR2epRyCDJqKXB3vHD5Vj2+l8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Josh Poimboeuf , Thomas Gleixner , Thadeu Lima de Souza Cascardo Subject: [PATCH 4.9 20/20] x86/speculation/mmio: Print SMT warning Date: Tue, 14 Jun 2022 20:40:03 +0200 Message-Id: <20220614183726.901907101@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220614183722.061550591@linuxfoundation.org> References: <20220614183722.061550591@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Josh Poimboeuf commit 1dc6ff02c8bf77d71b9b5d11cbc9df77cfb28626 upstream Similar to MDS and TAA, print a warning if SMT is enabled for the MMIO Stale Data vulnerability. Signed-off-by: Josh Poimboeuf Signed-off-by: Thomas Gleixner Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan --- arch/x86/kernel/cpu/bugs.c | 11 +++++++++++ 1 file changed, 11 insertions(+) --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -1214,6 +1214,7 @@ static void update_mds_branch_idle(void) =20 #define MDS_MSG_SMT "MDS CPU bug present and SMT on, data leak possible. S= ee https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for = more details.\n" #define TAA_MSG_SMT "TAA CPU bug present and SMT on, data leak possible. S= ee https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/tsx_async_abo= rt.html for more details.\n" +#define MMIO_MSG_SMT "MMIO Stale Data CPU bug present and SMT on, data lea= k possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/= processor_mmio_stale_data.html for more details.\n" =20 void arch_smt_update(void) { @@ -1258,6 +1259,16 @@ void arch_smt_update(void) break; } =20 + switch (mmio_mitigation) { + case MMIO_MITIGATION_VERW: + case MMIO_MITIGATION_UCODE_NEEDED: + if (sched_smt_active()) + pr_warn_once(MMIO_MSG_SMT); + break; + case MMIO_MITIGATION_OFF: + break; + } + mutex_unlock(&spec_ctrl_mutex); }