mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ashok Raj <ashok.raj@intel.com>
To: Borislav Petkov <bp@alien8.de>, Thomas Gleixner <tglx@linutronix.de>
Cc: "LKML Mailing List" <linux-kernel@vger.kernel.org>,
	X86-kernel <x86@kernel.org>, Tony Luck <tony.luck@intel.com>,
	Dave Hansen <dave.hansen@intel.com>,
	Arjan van de Ven <arjan.van.de.ven@intel.com>,
	Andy Lutomirski <luto@kernel.org>,
	Jacon Jun Pan <jacob.jun.pan@intel.com>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Kai Huang <kai.huang@intel.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ashok Raj <ashok.raj@intel.com>
Subject: [v2 08/13] x86/mce: Warn of a microcode update is in progress when MCE arrives
Date: Thu,  3 Nov 2022 17:58:56 +0000	[thread overview]
Message-ID: <20221103175901.164783-9-ashok.raj@intel.com> (raw)
In-Reply-To: <20221103175901.164783-1-ashok.raj@intel.com>

Due to the nature of microcode updates to long flow instructions, its
possible if an MCE is taken when microcode update is in progress could be
dangerous. There is nothing the kernel can do to mitigate safely.

Drop some bread crumbs to note that a MCE happened while a microcode update
is also in progress.

Suggested-by: Boris Petkov <bp@alien8.de>
Reviewed-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Ashok Raj <ashok.raj@intel.com>
---
 arch/x86/include/asm/microcode.h     | 2 ++
 arch/x86/kernel/cpu/mce/core.c       | 5 +++++
 arch/x86/kernel/cpu/microcode/core.c | 9 +++++++++
 3 files changed, 16 insertions(+)

diff --git a/arch/x86/include/asm/microcode.h b/arch/x86/include/asm/microcode.h
index ffb46f2b0354..f16973fb7330 100644
--- a/arch/x86/include/asm/microcode.h
+++ b/arch/x86/include/asm/microcode.h
@@ -167,8 +167,10 @@ static inline void microcode_bsp_resume(void)			{ }
 #endif
 
 #ifdef CONFIG_MICROCODE_LATE_LOADING
+extern int ucode_update_in_progress(void);
 extern void hold_sibling_in_nmi(void);
 #else
+static inline int ucode_update_in_progress(void) { return 0; }
 static inline void hold_sibling_in_nmi(void) { }
 #endif
 
diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
index 2c8ec5c71712..67669686fab4 100644
--- a/arch/x86/kernel/cpu/mce/core.c
+++ b/arch/x86/kernel/cpu/mce/core.c
@@ -46,6 +46,7 @@
 #include <linux/hardirq.h>
 
 #include <asm/intel-family.h>
+#include <asm/microcode.h>
 #include <asm/processor.h>
 #include <asm/traps.h>
 #include <asm/tlbflush.h>
@@ -1425,6 +1426,10 @@ noinstr void do_machine_check(struct pt_regs *regs)
 	else if (unlikely(!mca_cfg.initialized))
 		return unexpected_machine_check(regs);
 
+	instrumentation_begin();
+	if (ucode_update_in_progress())
+		pr_warn("MCE triggered while microcode update is in progress\n");
+	instrumentation_end();
 	if (mce_flags.skx_repmov_quirk && quirk_skylake_repmov())
 		goto clear;
 
diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c
index 6084a87ea8f3..6f59ffdf2881 100644
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -327,6 +327,8 @@ void reload_early_microcode(void)
 static struct platform_device	*microcode_pdev;
 
 #ifdef CONFIG_MICROCODE_LATE_LOADING
+static int ucode_updating;
+
 /*
  * Late loading dance. Why the heavy-handed stomp_machine effort?
  *
@@ -556,6 +558,11 @@ static void microcode_check(struct cpuinfo_x86 *orig)
 	pr_warn("x86/CPU: Please consider either early loading through initrd/built-in or a potential BIOS update.\n");
 }
 
+int ucode_update_in_progress(void)
+{
+	return ucode_updating;
+}
+
 /*
  * Reload microcode late on all CPUs. Wait for a sec until they
  * all gather together.
@@ -578,7 +585,9 @@ static int microcode_reload_late(void)
 	}
 
 	copy_cpu_caps(&info);
+	ucode_updating = 1;
 	ret = stop_machine_cpuslocked(__reload_late, NULL, cpu_online_mask);
+	ucode_updating = 0;
 	if (ret == 0)
 		microcode_check(&info);
 
-- 
2.34.1


  parent reply	other threads:[~2022-11-03 18:00 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-03 17:58 [v2 00/13] Make microcode late loading more robust Ashok Raj
2022-11-03 17:58 ` [v2 01/13] x86/microcode/intel: Prevent printing updated microcode rev multiple times Ashok Raj
2022-11-04 11:00   ` Borislav Petkov
2022-11-04 13:53     ` Van De Ven, Arjan
2022-11-04 15:52       ` Borislav Petkov
2022-11-04 18:28         ` Ashok Raj
2022-11-04 20:21           ` Borislav Petkov
2022-11-06 13:35   ` Borislav Petkov
2022-11-07  4:17     ` Ashok Raj
2022-11-07 16:12     ` Ashok Raj
2022-11-07 18:47       ` Borislav Petkov
2022-11-08 23:06         ` Ashok Raj
2022-11-08 23:32           ` Dave Hansen
2022-11-09  9:18           ` Borislav Petkov
2022-12-03 13:51   ` [tip: x86/microcode] x86/microcode/intel: Do not print microcode revision and processor flags tip-bot2 for Ashok Raj
2022-11-03 17:58 ` [v2 02/13] x86/microcode/intel: Print old and new rev after early microcode update Ashok Raj
2022-11-03 17:58 ` [v2 03/13] x86/microcode/intel: Fix a hang if early loading microcode fails Ashok Raj
2022-11-09 11:25   ` Borislav Petkov
2022-11-09 16:07     ` Ashok Raj
2022-11-09 23:34       ` Borislav Petkov
2022-11-03 17:58 ` [v2 04/13] x86/microcode: Fix microcode_check() compare after a new uCode update Ashok Raj
2022-11-03 17:58 ` [v2 05/13] x86/microcode: Move late-load warning to earlier where kernel taint happens Ashok Raj
2022-11-03 17:58 ` [v2 06/13] x86/ipi: Support sending NMI_VECTOR as self ipi Ashok Raj
2022-11-03 17:58 ` [v2 07/13] x86/microcode: Place siblings in NMI loop while update in progress Ashok Raj
2022-11-03 17:58 ` Ashok Raj [this message]
2022-11-03 17:58 ` [v2 09/13] x86/microcode/intel: Add minimum required revision to microcode header Ashok Raj
2022-11-03 17:58 ` [v2 10/13] x86/microcode: Add a generic mechanism to declare support for minrev Ashok Raj
2022-11-03 17:58 ` [v2 11/13] x86/microcode/intel: Drop wbinvd() from microcode loading Ashok Raj
2022-11-03 17:59 ` [v2 12/13] x86/microcode: Display revisions only when update is successful Ashok Raj
2022-11-03 17:59 ` [v2 13/13] x86/microcode/intel: Add ability to update microcode even if rev is unchanged Ashok Raj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221103175901.164783-9-ashok.raj@intel.com \
    --to=ashok.raj@intel.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=arjan.van.de.ven@intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=jacob.jun.pan@intel.com \
    --cc=kai.huang@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®