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 10/13] x86/microcode: Add a generic mechanism to declare support for minrev
Date: Thu,  3 Nov 2022 17:58:58 +0000	[thread overview]
Message-ID: <20221103175901.164783-11-ashok.raj@intel.com> (raw)
In-Reply-To: <20221103175901.164783-1-ashok.raj@intel.com>

Intel microcode adds some meta-data to report a minimum required revision
before this new microcode can be late-loaded. There are no generic mechanism
to declare support for all vendors.

Add generic support to microcode to declare support, so the tainting and
late-loading can be permitted in those architectures that support reporting
a minrev in some form.

Late loading has added support for

- New images declaring a required minimum base version before a late-load
  is performed.
- Improved NMI handling during update to avoid sibling threads taking NMI's
  while primary is still not complete with the microcode update.

With these changes, late-loading can be re-enabled. Tainting only happens
on architectures that don't support minimum required version reporting.

Reviewed-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Ashok Raj <ashok.raj@intel.com>
---
v2: (Kai) Add missing initialization local variable minrev

 arch/x86/include/asm/microcode.h      |  2 ++
 arch/x86/kernel/cpu/microcode/core.c  | 15 +++++++++++----
 arch/x86/kernel/cpu/microcode/intel.c |  6 ++++++
 arch/x86/Kconfig                      |  7 ++++---
 4 files changed, 23 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/microcode.h b/arch/x86/include/asm/microcode.h
index f16973fb7330..6286b4056792 100644
--- a/arch/x86/include/asm/microcode.h
+++ b/arch/x86/include/asm/microcode.h
@@ -64,6 +64,8 @@ enum ucode_state {
 };
 
 struct microcode_ops {
+	int (*check_minrev) (void);
+
 	enum ucode_state (*request_microcode_fw) (int cpu, struct device *);
 
 	void (*microcode_fini_cpu) (int cpu);
diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c
index 6f59ffdf2881..17dba13d397d 100644
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -607,6 +607,7 @@ static ssize_t reload_store(struct device *dev,
 	enum ucode_state tmp_ret = UCODE_OK;
 	int bsp = boot_cpu_data.cpu_index;
 	unsigned long val;
+	int minrev = 0;
 	ssize_t ret = 0;
 
 	ret = kstrtoul(buf, 0, &val);
@@ -622,13 +623,18 @@ static ssize_t reload_store(struct device *dev,
 	if (ret)
 		goto put;
 
+	if (microcode_ops->check_minrev)
+		minrev = microcode_ops->check_minrev();
+
+	if (!minrev) {
+		pr_err("Attempting late microcode loading - it is dangerous and taints the kernel.\n");
+		pr_err("You should switch to early loading, if possible.\n");
+	}
+
 	tmp_ret = microcode_ops->request_microcode_fw(bsp, &microcode_pdev->dev);
 	if (tmp_ret != UCODE_NEW)
 		goto put;
 
-	pr_err("Attempting late microcode loading - it is dangerous and taints the kernel.\n");
-	pr_err("You should switch to early loading, if possible.\n");
-
 	mutex_lock(&microcode_mutex);
 	ret = microcode_reload_late();
 	mutex_unlock(&microcode_mutex);
@@ -639,7 +645,8 @@ static ssize_t reload_store(struct device *dev,
 	if (ret == 0)
 		ret = size;
 
-	add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK);
+	if (!minrev)
+		add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK);
 
 	return ret;
 }
diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c
index 020d0feed3cc..5d2ee76cd36c 100644
--- a/arch/x86/kernel/cpu/microcode/intel.c
+++ b/arch/x86/kernel/cpu/microcode/intel.c
@@ -956,7 +956,13 @@ static enum ucode_state request_microcode_fw(int cpu, struct device *device)
 	return ret;
 }
 
+static int intel_check_minrev(void)
+{
+	return 1;
+}
+
 static struct microcode_ops microcode_intel_ops = {
+	.check_minrev			  = intel_check_minrev,
 	.request_microcode_fw             = request_microcode_fw,
 	.collect_cpu_info                 = collect_cpu_info,
 	.apply_microcode                  = apply_microcode_intel,
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 6d1879ef933a..b53626bff5f7 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1353,15 +1353,16 @@ config MICROCODE_AMD
 	  processors will be enabled.
 
 config MICROCODE_LATE_LOADING
-	bool "Late microcode loading (DANGEROUS)"
-	default n
+	bool "Late microcode loading"
+	default y
 	depends on MICROCODE
 	help
 	  Loading microcode late, when the system is up and executing instructions
 	  is a tricky business and should be avoided if possible. Just the sequence
 	  of synchronizing all cores and SMT threads is one fragile dance which does
 	  not guarantee that cores might not softlock after the loading. Therefore,
-	  use this at your own risk. Late loading taints the kernel too.
+	  use this at your own risk. Late loading taints the kernel, if it
+	  doesn't support a minimum required base version before an update.
 
 config X86_MSR
 	tristate "/dev/cpu/*/msr - Model-specific register support"
-- 
2.34.1


  parent reply	other threads:[~2022-11-03 18:01 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 ` [v2 08/13] x86/mce: Warn of a microcode update is in progress when MCE arrives Ashok Raj
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 ` Ashok Raj [this message]
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-11-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®