linux-kernel - linux-next: manual merge of the tip tree with Linus' tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20250513164944.462eec63@canb.auug.org.au>
Date: Tue, 13 May 2025 16:49:44 +1000
From: Stephen Rothwell <sfr@...b.auug.org.au>
To: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...nel.org>,
 "H. Peter Anvin" <hpa@...or.com>, Peter Zijlstra <peterz@...radead.org>
Cc: Dave Hansen <dave.hansen@...ux.intel.com>, Linux Kernel Mailing List
 <linux-kernel@...r.kernel.org>, Linux Next Mailing List
 <linux-next@...r.kernel.org>, Pawan Gupta
 <pawan.kumar.gupta@...ux.intel.com>
Subject: linux-next: manual merge of the tip tree with Linus' tree

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  arch/x86/kernel/cpu/common.c

between commit:

  159013a7ca18 ("x86/its: Enumerate Indirect Target Selection (ITS) bug")

from Linus' tree and commit:

  4e2c719782a8 ("x86/cpu: Help users notice when running old Intel microcode")

from the tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/kernel/cpu/common.c
index 0ff057ff11ce,34efb9d2519a..000000000000
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@@ -1325,32 -1320,42 +1327,68 @@@ static bool __init vulnerable_to_rfds(u
  	return cpu_matches(cpu_vuln_blacklist, RFDS);
  }

 +static bool __init vulnerable_to_its(u64 x86_arch_cap_msr)
 +{
 +	/* The "immunity" bit trumps everything else: */
 +	if (x86_arch_cap_msr & ARCH_CAP_ITS_NO)
 +		return false;
 +	if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
 +		return false;
 +
 +	/* None of the affected CPUs have BHI_CTRL */
 +	if (boot_cpu_has(X86_FEATURE_BHI_CTRL))
 +		return false;
 +
 +	/*
 +	 * If a VMM did not expose ITS_NO, assume that a guest could
 +	 * be running on a vulnerable hardware or may migrate to such
 +	 * hardware.
 +	 */
 +	if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
 +		return true;
 +
 +	if (cpu_matches(cpu_vuln_blacklist, ITS))
 +		return true;
 +
 +	return false;
 +}
 +
+ static struct x86_cpu_id cpu_latest_microcode[] = {
+ #include "microcode/intel-ucode-defs.h"
+ 	{}
+ };
+ 
+ static bool __init cpu_has_old_microcode(void)
+ {
+ 	const struct x86_cpu_id *m = x86_match_cpu(cpu_latest_microcode);
+ 
+ 	/* Give unknown CPUs a pass: */
+ 	if (!m) {
+ 		/* Intel CPUs should be in the list. Warn if not: */
+ 		if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL)
+ 			pr_info("x86/CPU: Model not found in latest microcode list\n");
+ 		return false;
+ 	}
+ 
+ 	/*
+ 	 * Hosts usually lie to guests with a super high microcode
+ 	 * version. Just ignore what hosts tell guests:
+ 	 */
+ 	if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
+ 		return false;
+ 
+ 	/* Consider all debug microcode to be old: */
+ 	if (boot_cpu_data.microcode & BIT(31))
+ 		return true;
+ 
+ 	/* Give new microcode a pass: */
+ 	if (boot_cpu_data.microcode >= m->driver_data)
+ 		return false;
+ 
+ 	/* Uh oh, too old: */
+ 	return true;
+ }
+ 
  static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c)
  {
  	u64 x86_arch_cap_msr = x86_read_arch_cap_msr();

Content of type "application/pgp-signature" skipped