[GIT PULL] x86/microcode for 6.7

[GIT PULL] x86/microcode for 6.7

[Borislav Petkov]

Hi Linus,

I believe this is the last tip branch from the lineup this merge window.
It has a lot of nice things, it has been tested on everything we have
access to so it should be good. There's a trivial merge conflict with
your current tree (8f6f76a6a29f) which I'm pasting at the end of this
mail, just in case.

Please pull,
thx.

---

The following changes since commit 58720809f52779dc0f08e53e54b014209d13eebb:

  Linux 6.6-rc6 (2023-10-15 13:34:39 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86_microcode_for_v6.7_rc1

for you to fetch changes up to cf5ab01c87030a085e211a0a327535932ec6f719:

  x86/microcode/intel: Add a minimum required revision for late loading (2023-10-24 15:05:55 +0200)

----------------------------------------------------------------
Major microcode loader restructuring, cleanup and improvements by Thomas
Gleixner:

- Restructure the code needed for it and add a temporary initrd mapping
  on 32-bit so that the loader can access the microcode blobs. This in
  itself is a preparation for the next major improvement:

- Do not load microcode on 32-bit before paging has been enabled.
  Handling this has caused an endless stream of headaches, issues, ugly
  code and unnecessary hacks in the past. And there really wasn't any
  sensible reason to do that in the first place. So switch the 32-bit
  loading to happen after paging has been enabled and turn the loader
  code "real purrty" again

- Drop mixed microcode steppings loading on Intel - there, a single patch
  loaded on the whole system is sufficient

- Rework late loading to track which CPUs have updated microcode
  successfully and which haven't, act accordingly

- Move late microcode loading on Intel in NMI context in order to
  guarantee concurrent loading on all threads

- Make the late loading CPU-hotplug-safe and have the offlined threads
  be woken up for the purpose of the update

- Add support for a minimum revision which determines whether late
  microcode loading is safe on a machine and the microcode does not
  change software visible features which the machine cannot use anyway
  since feature detection has happened already. Roughly, the minimum
  revision is the smallest revision number which must be loaded
  currently on the system so that late updates can be allowed

- Other nice leanups, fixess, etc all over the place

----------------------------------------------------------------
Ashok Raj (2):
      x86/microcode/intel: Rip out mixed stepping support for Intel CPUs
      x86/microcode/intel: Add a minimum required revision for late loading

Paolo Bonzini (1):
      x86/microcode/amd: Fix snprintf() format string warning in W=1 build

Thomas Gleixner (37):
      x86/boot/32: Disable stackprotector and tracing for mk_early_pgtbl_32()
      x86/boot: Use __pa_nodebug() in mk_early_pgtbl_32()
      x86/boot/32: De-uglify the 2/3 level paging difference in mk_early_pgtbl_32()
      x86/boot/32: Restructure mk_early_pgtbl_32()
      x86/microcode: Provide CONFIG_MICROCODE_INITRD32
      x86/boot/32: Temporarily map initrd for microcode loading
      x86/microcode/32: Move early loading after paging enable
      x86/microcode/intel: Simplify scan_microcode()
      x86/microcode/intel: Simplify and rename generic_load_microcode()
      x86/microcode/intel: Cleanup code further
      x86/microcode/intel: Simplify early loading
      x86/microcode/intel: Save the microcode only after a successful late-load
      x86/microcode/intel: Switch to kvmalloc()
      x86/microcode/intel: Unify microcode apply() functions
      x86/microcode/intel: Rework intel_cpu_collect_info()
      x86/microcode/intel: Reuse intel_cpu_collect_info()
      x86/microcode/intel: Rework intel_find_matching_signature()
      x86/microcode: Remove pointless apply() invocation
      x86/microcode/amd: Use correct per CPU ucode_cpu_info
      x86/microcode/amd: Cache builtin microcode too
      x86/microcode/amd: Cache builtin/initrd microcode early
      x86/microcode/amd: Use cached microcode for AP load
      x86/microcode: Mop up early loading leftovers
      x86/microcode: Get rid of the schedule work indirection
      x86/microcode: Clean up mc_cpu_down_prep()
      x86/microcode: Handle "nosmt" correctly
      x86/microcode: Clarify the late load logic
      x86/microcode: Sanitize __wait_for_cpus()
      x86/microcode: Add per CPU result state
      x86/microcode: Add per CPU control field
      x86/microcode: Provide new control functions
      x86/microcode: Replace the all-in-one rendevous handler
      x86/microcode: Rendezvous and load in NMI
      x86/microcode: Protect against instrumentation
      x86/apic: Provide apic_force_nmi_on_cpu()
      x86/microcode: Handle "offline" CPUs correctly
      x86/microcode: Prepare for minimal revision check

 Documentation/admin-guide/kernel-parameters.txt |   5 +
 arch/x86/Kconfig                                |  29 +-
 arch/x86/include/asm/apic.h                     |   5 +-
 arch/x86/include/asm/cpu.h                      |  20 +-
 arch/x86/include/asm/microcode.h                |  21 +-
 arch/x86/include/asm/setup.h                    |   1 +
 arch/x86/kernel/Makefile                        |   1 +
 arch/x86/kernel/apic/apic_flat_64.c             |   2 +
 arch/x86/kernel/apic/ipi.c                      |   8 +
 arch/x86/kernel/apic/x2apic_cluster.c           |   1 +
 arch/x86/kernel/apic/x2apic_phys.c              |   1 +
 arch/x86/kernel/cpu/common.c                    |  12 -
 arch/x86/kernel/cpu/microcode/amd.c             | 157 +++---
 arch/x86/kernel/cpu/microcode/core.c            | 670 ++++++++++++++---------
 arch/x86/kernel/cpu/microcode/intel.c           | 688 ++++++++----------------
 arch/x86/kernel/cpu/microcode/internal.h        |  35 +-
 arch/x86/kernel/head32.c                        | 120 +++--
 arch/x86/kernel/head_32.S                       |  10 -
 arch/x86/kernel/nmi.c                           |   9 +-
 arch/x86/kernel/smpboot.c                       |  12 +-
 drivers/platform/x86/intel/ifs/load.c           |   8 +-
 21 files changed, 905 insertions(+), 910 deletions(-)

---

merge conflict resolve:

diff --cc arch/x86/include/asm/apic.h
index b0d192f613b7,17f2f28a495e..d21f48f1c242
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@@ -528,12 -539,15 +529,14 @@@ extern int default_apic_id_valid(u32 ap
  extern u32 apic_default_calc_apicid(unsigned int cpu);
  extern u32 apic_flat_calc_apicid(unsigned int cpu);
  
 -extern bool default_check_apicid_used(physid_mask_t *map, int apicid);
  extern void default_ioapic_phys_id_map(physid_mask_t *phys_map, physid_mask_t *retmap);
 -extern int default_cpu_present_to_apicid(int mps_cpu);
 +extern u32 default_cpu_present_to_apicid(int mps_cpu);
  
+ void apic_send_nmi_to_offline_cpu(unsigned int cpu);
+ 
  #else /* CONFIG_X86_LOCAL_APIC */
  
 -static inline unsigned int read_apic_id(void) { return 0; }
 +static inline u32 read_apic_id(void) { return 0; }
  
  #endif /* !CONFIG_X86_LOCAL_APIC */
  

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [GIT PULL] x86/microcode for 6.7

[pr-tracker-bot]

The pull request you sent on Fri, 3 Nov 2023 12:06:00 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86_microcode_for_v6.7_rc1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/0a23fb262d17f587c9bb1e6cc83ad4158b21f16e

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] x86/microcode for 6.7

[Linus Torvalds]

On Fri, 3 Nov 2023 at 04:06, Borislav Petkov <bp@alien8.de> wrote:
>
> I believe this is the last tip branch from the lineup this merge window.
> It has a lot of nice things, it has been tested on everything we have
> access to so it should be good.

Well, I only now looked more closely at dmesg (because I was testing
an entirely unrelated patch of mine), and I see this:

    smpboot: x86: Booting SMP configuration:
    .... node  #0, CPUs:        #1  #2  #3  #4  #5
    microcode: CPU4: new patch_level=0x0830107a
      #6
    microcode: CPU5: new patch_level=0x0830107a
      #7
    microcode: CPU1: new patch_level=0x0830107a
    microcode: CPU2: new patch_level=0x0830107a
    microcode: CPU3: new patch_level=0x0830107a
    microcode: CPU6: new patch_level=0x0830107a
      #8
    ...
      #63
    microcode: CPU62: new patch_level=0x0830107a
    microcode: CPU63: new patch_level=0x0830107a
    smp: Brought up 1 node, 64 CPUs
    ...
    mip6: Mobile IPv6
    NET: Registered PF_PACKET protocol family
    microcode: microcode updated early to new patch_level=0x0830107a
    microcode: CPU0: patch_level=0x0830107a
    microcode: CPU1: patch_level=0x0830107a
    microcode: CPU2: patch_level=0x0830107a
    ..
    microcode: CPU62: patch_level=0x0830107a
    microcode: CPU63: patch_level=0x0830107a
    microcode: Microcode Update Driver: v2.2.

which is really quite ugly and entirely pointless.

I *really* don't want to be told 129 times that my microcode has been
updated to the same level.

And yes, it's "only" 129 times, because while there are two of those
microcode update lines:

    microcode: microcode updated early to new patch_level=0x0830107a
    microcode: Microcode Update Driver: v2.2.

CPU#0 is only mentioned once, while CPU's 1..63 all get two mentions
(once for the bringup, once fro the summary).

Can we please stop doing this insanity? It's not helpful.

                 Linus

Re: [GIT PULL] x86/microcode for 6.7

[Borislav Petkov]

On Sat, Nov 11, 2023 at 02:19:00PM -0800, Linus Torvalds wrote:
> Can we please stop doing this insanity? It's not helpful.

Yeah, it is on the todo list. I'll take a look next week.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [GIT PULL] x86/microcode for 6.7

[Borislav Petkov]

On Sat, Nov 11, 2023 at 11:35:49PM +0100, Borislav Petkov wrote:
> Yeah, it is on the todo list. I'll take a look next week.

Yeah, so I think something along the lines of the below.

This has been bothering me for a while now too but I wanted to get
tglx's stuff taken care of first.

Basically, we can simply report the previous and the potentially new
revision only once on driver load.

Even if the AMD side theoretically still supports mixed silicon
steppings, there's no need to do per-thread reporting as that info is
already in /proc/cpuinfo for those who are really interested.

So this below should be good enough.

I'll test it some more next week and split it.

diff --git a/arch/x86/kernel/cpu/microcode/amd.c b/arch/x86/kernel/cpu/microcode/amd.c
index 9373ec01c5ae..7213dea21a15 100644
--- a/arch/x86/kernel/cpu/microcode/amd.c
+++ b/arch/x86/kernel/cpu/microcode/amd.c
@@ -104,7 +104,7 @@ struct cont_desc {
 	size_t		     size;
 };
 
-static u32 ucode_new_rev;
+static u32 early_new_rev, old_rev;
 
 /*
  * Microcode patch container file is prepended to the initrd in cpio
@@ -447,7 +447,6 @@ static bool early_apply_microcode(u32 cpuid_1_eax, void *ucode, size_t size)
 	struct cont_desc desc = { 0 };
 	struct microcode_amd *mc;
 	bool ret = false;
-	u32 rev, dummy;
 
 	desc.cpuid_1_eax = cpuid_1_eax;
 
@@ -457,22 +456,15 @@ static bool early_apply_microcode(u32 cpuid_1_eax, void *ucode, size_t size)
 	if (!mc)
 		return ret;
 
-	native_rdmsr(MSR_AMD64_PATCH_LEVEL, rev, dummy);
-
 	/*
 	 * Allow application of the same revision to pick up SMT-specific
 	 * changes even if the revision of the other SMT thread is already
 	 * up-to-date.
 	 */
-	if (rev > mc->hdr.patch_id)
+	if (old_rev > mc->hdr.patch_id)
 		return ret;
 
-	if (!__apply_microcode_amd(mc)) {
-		ucode_new_rev = mc->hdr.patch_id;
-		ret = true;
-	}
-
-	return ret;
+	return !__apply_microcode_amd(mc);
 }
 
 static bool get_builtin_microcode(struct cpio_data *cp, unsigned int family)
@@ -509,6 +501,9 @@ static void __init find_blobs_in_containers(unsigned int cpuid_1_eax, struct cpi
 void __init load_ucode_amd_bsp(unsigned int cpuid_1_eax)
 {
 	struct cpio_data cp = { };
+	u32 dummy;
+
+	native_rdmsr(MSR_AMD64_PATCH_LEVEL, old_rev, dummy);
 
 	/* Needed in load_microcode_amd() */
 	ucode_cpu_info[0].cpu_sig.sig = cpuid_1_eax;
@@ -517,7 +512,8 @@ void __init load_ucode_amd_bsp(unsigned int cpuid_1_eax)
 	if (!(cp.data && cp.size))
 		return;
 
-	early_apply_microcode(cpuid_1_eax, cp.data, cp.size);
+	if (early_apply_microcode(cpuid_1_eax, cp.data, cp.size))
+		native_rdmsr(MSR_AMD64_PATCH_LEVEL, early_new_rev, dummy);
 }
 
 static enum ucode_state load_microcode_amd(u8 family, const u8 *data, size_t size);
@@ -626,8 +622,8 @@ void reload_ucode_amd(unsigned int cpu)
 
 	if (rev < mc->hdr.patch_id) {
 		if (!__apply_microcode_amd(mc)) {
-			ucode_new_rev = mc->hdr.patch_id;
-			pr_info("reload patch_level=0x%08x\n", ucode_new_rev);
+			early_new_rev = mc->hdr.patch_id;
+			pr_info_once("reload revision: 0x%08x\n", early_new_rev);
 		}
 	}
 }
@@ -649,8 +645,6 @@ static int collect_cpu_info_amd(int cpu, struct cpu_signature *csig)
 	if (p && (p->patch_id == csig->rev))
 		uci->mc = p->data;
 
-	pr_info("CPU%d: patch_level=0x%08x\n", cpu, csig->rev);
-
 	return 0;
 }
 
@@ -691,8 +685,6 @@ static enum ucode_state apply_microcode_amd(int cpu)
 	rev = mc_amd->hdr.patch_id;
 	ret = UCODE_UPDATED;
 
-	pr_info("CPU%d: new patch_level=0x%08x\n", cpu, rev);
-
 out:
 	uci->cpu_sig.rev = rev;
 	c->microcode	 = rev;
@@ -936,9 +928,11 @@ struct microcode_ops * __init init_amd_microcode(void)
 		return NULL;
 	}
 
-	if (ucode_new_rev)
-		pr_info_once("microcode updated early to new patch_level=0x%08x\n",
-			     ucode_new_rev);
+	pr_info_once("Current revision: 0x%08x\n", (early_new_rev ?: old_rev));
+
+	if (early_new_rev)
+		pr_info_once("Updated early from: 0x%08x\n",
+			     old_rev);
 
 	return &microcode_amd_ops;
 }
diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c
index 666d25bbc5ad..b4be3a2c79df 100644
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -41,8 +41,6 @@
 
 #include "internal.h"
 
-#define DRIVER_VERSION	"2.2"
-
 static struct microcode_ops	*microcode_ops;
 bool dis_ucode_ldr = true;
 
@@ -846,8 +844,6 @@ static int __init microcode_init(void)
 	cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "x86/microcode:online",
 			  mc_cpu_online, mc_cpu_down_prep);
 
-	pr_info("Microcode Update Driver: v%s.", DRIVER_VERSION);
-
 	return 0;
 
  out_pdev:

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [GIT PULL] x86/microcode for 6.7

[Linus Torvalds]

On Sun, 12 Nov 2023 at 04:23, Borislav Petkov <bp@alien8.de> wrote:
>
> Yeah, so I think something along the lines of the below.

I can verify that this makes my boot logs look sane again.

I'm not applying this directly, and will let you do the final version
in the tip tree (split into two?), but thought I'd at least ack that
it works for me.

                 Linus

Re: [GIT PULL] x86/microcode for 6.7

[Borislav Petkov]

On Sun, Nov 12, 2023 at 11:41:53AM -0800, Linus Torvalds wrote:
> I can verify that this makes my boot logs look sane again.

Cool.

> I'm not applying this directly, and will let you do the final version
> in the tip tree (split into two?), but thought I'd at least ack that
> it works for me.

Thanks!

So I was looking at the Intel side earlier and it doesn't dump the
revision it had *before* the early loading. And people have asked for
that functionality - to be able to dump the revision which got
overwritten.

So I'll try to pull up that code and use for both drivers, test on all
machines and send out a proper set.

And yap, you'll get that eventually through tip, in time for 6.7.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette