linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2 0/5] x86: cpuid: improve support for broken CPUID configurations
@ 2022-07-18 14:11 Maxim Levitsky
  2022-07-18 14:11 ` [PATCH v2 1/5] perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap Maxim Levitsky
                   ` (5 more replies)
  0 siblings, 6 replies; 31+ messages in thread
From: Maxim Levitsky @ 2022-07-18 14:11 UTC (permalink / raw)
  To: linux-kernel, kvm
  Cc: Pawan Gupta, Ingo Molnar, Josh Poimboeuf, Namhyung Kim,
	Tony Luck, Paolo Bonzini, H. Peter Anvin,
	Arnaldo Carvalho de Melo, Thomas Gleixner, Alexander Shishkin,
	Tim Chen, Borislav Petkov, David S. Miller, Dave Hansen,
	Chang S. Bae, Jane Malalane, Kees Cook, Kan Liang,
	Peter Zijlstra, Maxim Levitsky,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Herbert Xu, Jiri Olsa, Mark Rutland, linux-perf-users,
	open list:CRYPTO API

This patch series aims to harden the cpuid code against the case when
the hypervisor exposes a broken CPUID configuration to the guest,
in the form of having a feature disabled but not features that depend on it.

This is the more generic way to fix kernel panic in aes-ni kernel driver,
which was triggered by CPUID configuration in which AVX is disabled but
not AVX2.

https://lore.kernel.org/all/20211103145231.GA4485@gondor.apana.org.au/T/

This was tested by booting a guest with AVX disabled and not AVX2,
and observing that both a warning is now printed in dmesg, and
that avx2 is gone from /proc/cpuinfo.

V2:

I hopefully addressed all the (very good) review feedback.

Best regards,
	Maxim Levitsky

Maxim Levitsky (5):
  perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap
  x86/cpuid: refactor setup_clear_cpu_cap()/clear_cpu_cap()
  x86/cpuid: move filter_cpuid_features to cpuid-deps.c
  x86/cpuid: remove 'warn' parameter from filter_cpuid_features
  x86/cpuid: check for dependencies violations in CPUID and attempt to
    fix them

 arch/x86/events/intel/lbr.c       |  2 +-
 arch/x86/include/asm/cpufeature.h |  1 +
 arch/x86/kernel/cpu/common.c      | 51 +-------------------
 arch/x86/kernel/cpu/cpuid-deps.c  | 80 +++++++++++++++++++++++++++----
 4 files changed, 74 insertions(+), 60 deletions(-)

-- 
2.34.3



^ permalink raw reply	[flat|nested] 31+ messages in thread

* [PATCH v2 1/5] perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap
  2022-07-18 14:11 [PATCH v2 0/5] x86: cpuid: improve support for broken CPUID configurations Maxim Levitsky
@ 2022-07-18 14:11 ` Maxim Levitsky
  2022-09-19 14:31   ` Borislav Petkov
  2022-10-20 15:17   ` [tip: x86/urgent] perf/x86/intel/lbr: Use setup_clear_cpu_cap() instead of clear_cpu_cap() tip-bot2 for Maxim Levitsky
  2022-07-18 14:11 ` [PATCH v2 2/5] x86/cpuid: refactor setup_clear_cpu_cap()/clear_cpu_cap() Maxim Levitsky
                   ` (4 subsequent siblings)
  5 siblings, 2 replies; 31+ messages in thread
From: Maxim Levitsky @ 2022-07-18 14:11 UTC (permalink / raw)
  To: linux-kernel, kvm
  Cc: Pawan Gupta, Ingo Molnar, Josh Poimboeuf, Namhyung Kim,
	Tony Luck, Paolo Bonzini, H. Peter Anvin,
	Arnaldo Carvalho de Melo, Thomas Gleixner, Alexander Shishkin,
	Tim Chen, Borislav Petkov, David S. Miller, Dave Hansen,
	Chang S. Bae, Jane Malalane, Kees Cook, Kan Liang,
	Peter Zijlstra, Maxim Levitsky,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Herbert Xu, Jiri Olsa, Mark Rutland, linux-perf-users,
	open list:CRYPTO API

clear_cpu_cap(&boot_cpu_data) is very similar to setup_clear_cpu_cap
except that the latter also sets a bit in 'cpu_caps_cleared' which
later clears the same cap in secondary cpus, which is likely
what is meant here.

Fixes: 47125db27e47 ("perf/x86/intel/lbr: Support Architectural LBR")

Reviewed-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
---
 arch/x86/events/intel/lbr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c
index 13179f31fe10fa..b08715172309a7 100644
--- a/arch/x86/events/intel/lbr.c
+++ b/arch/x86/events/intel/lbr.c
@@ -1860,7 +1860,7 @@ void __init intel_pmu_arch_lbr_init(void)
 	return;
 
 clear_arch_lbr:
-	clear_cpu_cap(&boot_cpu_data, X86_FEATURE_ARCH_LBR);
+	setup_clear_cpu_cap(X86_FEATURE_ARCH_LBR);
 }
 
 /**
-- 
2.34.3


^ permalink raw reply related	[flat|nested] 31+ messages in thread

* [PATCH v2 2/5] x86/cpuid: refactor setup_clear_cpu_cap()/clear_cpu_cap()
  2022-07-18 14:11 [PATCH v2 0/5] x86: cpuid: improve support for broken CPUID configurations Maxim Levitsky
  2022-07-18 14:11 ` [PATCH v2 1/5] perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap Maxim Levitsky
@ 2022-07-18 14:11 ` Maxim Levitsky
  2022-10-21 16:19   ` Borislav Petkov
  2022-07-18 14:11 ` [PATCH v2 3/5] x86/cpuid: move filter_cpuid_features to cpuid-deps.c Maxim Levitsky
                   ` (3 subsequent siblings)
  5 siblings, 1 reply; 31+ messages in thread
From: Maxim Levitsky @ 2022-07-18 14:11 UTC (permalink / raw)
  To: linux-kernel, kvm
  Cc: Pawan Gupta, Ingo Molnar, Josh Poimboeuf, Namhyung Kim,
	Tony Luck, Paolo Bonzini, H. Peter Anvin,
	Arnaldo Carvalho de Melo, Thomas Gleixner, Alexander Shishkin,
	Tim Chen, Borislav Petkov, David S. Miller, Dave Hansen,
	Chang S. Bae, Jane Malalane, Kees Cook, Kan Liang,
	Peter Zijlstra, Maxim Levitsky,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Herbert Xu, Jiri Olsa, Mark Rutland, linux-perf-users,
	open list:CRYPTO API

Currently setup_clear_cpu_cap passes NULL 'struct cpuinfo_x86*'
to clear_cpu_cap to indicate that capability should be cleared from boot_cpu_data.

Later that is used in clear_feature to do recursive call to
clear_cpu_cap together with clearing the feature bit from 'cpu_caps_cleared'

Remove that code and just call the do_clear_cpu_cap on boot_cpu_data directly
from the setup_clear_cpu_cap.

The only functional change this introduces is that now calling clear_cpu_cap
explicitly on boot_cpu_data also sets the bits in cpu_caps_cleared,
which is the only thing that makes sense anyway.

All callers of both functions were checked for this and fixed.

Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
---
 arch/x86/kernel/cpu/cpuid-deps.c | 17 +++++------------
 1 file changed, 5 insertions(+), 12 deletions(-)

diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c
index c881bcafba7d70..d6777d07ba3302 100644
--- a/arch/x86/kernel/cpu/cpuid-deps.c
+++ b/arch/x86/kernel/cpu/cpuid-deps.c
@@ -88,18 +88,16 @@ static inline void clear_feature(struct cpuinfo_x86 *c, unsigned int feature)
 	 * rest of the cpufeature code uses atomics as well, so keep it for
 	 * consistency. Cleanup all of it separately.
 	 */
-	if (!c) {
-		clear_cpu_cap(&boot_cpu_data, feature);
+	clear_bit(feature, (unsigned long *)c->x86_capability);
+
+	if (c == &boot_cpu_data)
 		set_bit(feature, (unsigned long *)cpu_caps_cleared);
-	} else {
-		clear_bit(feature, (unsigned long *)c->x86_capability);
-	}
 }
 
 /* Take the capabilities and the BUG bits into account */
 #define MAX_FEATURE_BITS ((NCAPINTS + NBUGINTS) * sizeof(u32) * 8)
 
-static void do_clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int feature)
+void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int feature)
 {
 	DECLARE_BITMAP(disable, MAX_FEATURE_BITS);
 	const struct cpuid_dep *d;
@@ -129,12 +127,7 @@ static void do_clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int feature)
 	} while (changed);
 }
 
-void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int feature)
-{
-	do_clear_cpu_cap(c, feature);
-}
-
 void setup_clear_cpu_cap(unsigned int feature)
 {
-	do_clear_cpu_cap(NULL, feature);
+	clear_cpu_cap(&boot_cpu_data, feature);
 }
-- 
2.34.3


^ permalink raw reply related	[flat|nested] 31+ messages in thread

* [PATCH v2 3/5] x86/cpuid: move filter_cpuid_features to cpuid-deps.c
  2022-07-18 14:11 [PATCH v2 0/5] x86: cpuid: improve support for broken CPUID configurations Maxim Levitsky
  2022-07-18 14:11 ` [PATCH v2 1/5] perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap Maxim Levitsky
  2022-07-18 14:11 ` [PATCH v2 2/5] x86/cpuid: refactor setup_clear_cpu_cap()/clear_cpu_cap() Maxim Levitsky
@ 2022-07-18 14:11 ` Maxim Levitsky
  2022-07-18 14:11 ` [PATCH v2 4/5] x86/cpuid: remove 'warn' parameter from filter_cpuid_features Maxim Levitsky
                   ` (2 subsequent siblings)
  5 siblings, 0 replies; 31+ messages in thread
From: Maxim Levitsky @ 2022-07-18 14:11 UTC (permalink / raw)
  To: linux-kernel, kvm
  Cc: Pawan Gupta, Ingo Molnar, Josh Poimboeuf, Namhyung Kim,
	Tony Luck, Paolo Bonzini, H. Peter Anvin,
	Arnaldo Carvalho de Melo, Thomas Gleixner, Alexander Shishkin,
	Tim Chen, Borislav Petkov, David S. Miller, Dave Hansen,
	Chang S. Bae, Jane Malalane, Kees Cook, Kan Liang,
	Peter Zijlstra, Maxim Levitsky,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Herbert Xu, Jiri Olsa, Mark Rutland, linux-perf-users,
	open list:CRYPTO API

filter_cpuid_features performs a sanity check on CPU/hypervisor
provided CPUID in regard to having all required leaves which
some CPUID feature bits require.

Soon this sanity check will be extended to also disable CPUID
features which were erronsly enabled in CPUID and depend on
features that are marked as disabled in the CPUID.

It thus makes sense to have both checks in one file.

No functional change intended.

Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
---
 arch/x86/include/asm/cpufeature.h |  1 +
 arch/x86/kernel/cpu/common.c      | 47 -------------------------------
 arch/x86/kernel/cpu/cpuid-deps.c  | 47 +++++++++++++++++++++++++++++++
 3 files changed, 48 insertions(+), 47 deletions(-)

diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h
index ea34cc31b0474f..3eb5fe0d654e63 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -147,6 +147,7 @@ extern const char * const x86_bug_flags[NBUGINTS*32];
 
 extern void setup_clear_cpu_cap(unsigned int bit);
 extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit);
+extern void filter_cpuid_features(struct cpuinfo_x86 *c, bool warn);
 
 #define setup_force_cpu_cap(bit) do { \
 	set_cpu_cap(&boot_cpu_data, bit);	\
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 736262a76a12b7..beaea42c1b47e1 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -620,53 +620,6 @@ __noendbr void cet_disable(void)
 		wrmsrl(MSR_IA32_S_CET, 0);
 }
 
-/*
- * Some CPU features depend on higher CPUID levels, which may not always
- * be available due to CPUID level capping or broken virtualization
- * software.  Add those features to this table to auto-disable them.
- */
-struct cpuid_dependent_feature {
-	u32 feature;
-	u32 level;
-};
-
-static const struct cpuid_dependent_feature
-cpuid_dependent_features[] = {
-	{ X86_FEATURE_MWAIT,		0x00000005 },
-	{ X86_FEATURE_DCA,		0x00000009 },
-	{ X86_FEATURE_XSAVE,		0x0000000d },
-	{ 0, 0 }
-};
-
-static void filter_cpuid_features(struct cpuinfo_x86 *c, bool warn)
-{
-	const struct cpuid_dependent_feature *df;
-
-	for (df = cpuid_dependent_features; df->feature; df++) {
-
-		if (!cpu_has(c, df->feature))
-			continue;
-		/*
-		 * Note: cpuid_level is set to -1 if unavailable, but
-		 * extended_extended_level is set to 0 if unavailable
-		 * and the legitimate extended levels are all negative
-		 * when signed; hence the weird messing around with
-		 * signs here...
-		 */
-		if (!((s32)df->level < 0 ?
-		     (u32)df->level > (u32)c->extended_cpuid_level :
-		     (s32)df->level > (s32)c->cpuid_level))
-			continue;
-
-		clear_cpu_cap(c, df->feature);
-		if (!warn)
-			continue;
-
-		pr_warn("CPU: CPU feature " X86_CAP_FMT " disabled, no CPUID level 0x%x\n",
-			x86_cap_flag(df->feature), df->level);
-	}
-}
-
 /*
  * Naming convention should be: <Name> [(<Codename>)]
  * This table only is used unless init_<vendor>() below doesn't set it;
diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c
index d6777d07ba3302..306f285844aedc 100644
--- a/arch/x86/kernel/cpu/cpuid-deps.c
+++ b/arch/x86/kernel/cpu/cpuid-deps.c
@@ -131,3 +131,50 @@ void setup_clear_cpu_cap(unsigned int feature)
 {
 	clear_cpu_cap(&boot_cpu_data, feature);
 }
+
+/*
+ * Some CPU features depend on higher CPUID levels, which may not always
+ * be available due to CPUID level capping or broken virtualization
+ * software.  Add those features to this table to auto-disable them.
+ */
+struct cpuid_dependent_feature {
+	u32 feature;
+	u32 level;
+};
+
+static const struct cpuid_dependent_feature
+cpuid_dependent_features[] = {
+	{ X86_FEATURE_MWAIT,		0x00000005 },
+	{ X86_FEATURE_DCA,		0x00000009 },
+	{ X86_FEATURE_XSAVE,		0x0000000d },
+	{ 0, 0 }
+};
+
+void filter_cpuid_features(struct cpuinfo_x86 *c, bool warn)
+{
+	const struct cpuid_dependent_feature *df;
+
+	for (df = cpuid_dependent_features; df->feature; df++) {
+
+		if (!cpu_has(c, df->feature))
+			continue;
+		/*
+		 * Note: cpuid_level is set to -1 if unavailable, but
+		 * extended_extended_level is set to 0 if unavailable
+		 * and the legitimate extended levels are all negative
+		 * when signed; hence the weird messing around with
+		 * signs here...
+		 */
+		if (!((s32)df->level < 0 ?
+		     (u32)df->level > (u32)c->extended_cpuid_level :
+		     (s32)df->level > (s32)c->cpuid_level))
+			continue;
+
+		clear_cpu_cap(c, df->feature);
+		if (!warn)
+			continue;
+
+		pr_warn("CPU: CPU feature " X86_CAP_FMT " disabled, no CPUID level 0x%x\n",
+			x86_cap_flag(df->feature), df->level);
+	}
+}
-- 
2.34.3


^ permalink raw reply related	[flat|nested] 31+ messages in thread

* [PATCH v2 4/5] x86/cpuid: remove 'warn' parameter from filter_cpuid_features
  2022-07-18 14:11 [PATCH v2 0/5] x86: cpuid: improve support for broken CPUID configurations Maxim Levitsky
                   ` (2 preceding siblings ...)
  2022-07-18 14:11 ` [PATCH v2 3/5] x86/cpuid: move filter_cpuid_features to cpuid-deps.c Maxim Levitsky
@ 2022-07-18 14:11 ` Maxim Levitsky
  2022-07-18 14:11 ` [PATCH v2 5/5] x86/cpuid: check for dependencies violations in CPUID and attempt to fix them Maxim Levitsky
  2022-07-28  7:30 ` [PATCH v2 0/5] x86: cpuid: improve support for broken CPUID configurations Maxim Levitsky
  5 siblings, 0 replies; 31+ messages in thread
From: Maxim Levitsky @ 2022-07-18 14:11 UTC (permalink / raw)
  To: linux-kernel, kvm
  Cc: Pawan Gupta, Ingo Molnar, Josh Poimboeuf, Namhyung Kim,
	Tony Luck, Paolo Bonzini, H. Peter Anvin,
	Arnaldo Carvalho de Melo, Thomas Gleixner, Alexander Shishkin,
	Tim Chen, Borislav Petkov, David S. Miller, Dave Hansen,
	Chang S. Bae, Jane Malalane, Kees Cook, Kan Liang,
	Peter Zijlstra, Maxim Levitsky,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Herbert Xu, Jiri Olsa, Mark Rutland, linux-perf-users,
	open list:CRYPTO API

This parameter suppresses the warning if issue is found when
this function called from early boot cpu identification code, which doesn't
seem to be useful, except that it actually completely hides the warning,
because next time this code is called for each CPU and when the warning
is printed, the issue is already fixed, and so no warning is printed at all.

Tested by using a broken CPUID with missing leaf and observing no warning printed,
and with the patch a warning is printed once.

Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
---
 arch/x86/include/asm/cpufeature.h | 2 +-
 arch/x86/kernel/cpu/common.c      | 4 ++--
 arch/x86/kernel/cpu/cpuid-deps.c  | 4 +---
 3 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h
index 3eb5fe0d654e63..86d7fbb3f2b592 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -147,7 +147,7 @@ extern const char * const x86_bug_flags[NBUGINTS*32];
 
 extern void setup_clear_cpu_cap(unsigned int bit);
 extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit);
-extern void filter_cpuid_features(struct cpuinfo_x86 *c, bool warn);
+extern void filter_cpuid_features(struct cpuinfo_x86 *c);
 
 #define setup_force_cpu_cap(bit) do { \
 	set_cpu_cap(&boot_cpu_data, bit);	\
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index beaea42c1b47e1..1a2f4e83e2f312 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1485,7 +1485,7 @@ static void __init early_identify_cpu(struct cpuinfo_x86 *c)
 			this_cpu->c_early_init(c);
 
 		c->cpu_index = 0;
-		filter_cpuid_features(c, false);
+		filter_cpuid_features(c);
 
 		if (this_cpu->c_bsp_init)
 			this_cpu->c_bsp_init(c);
@@ -1773,7 +1773,7 @@ static void identify_cpu(struct cpuinfo_x86 *c)
 	 */
 
 	/* Filter out anything that depends on CPUID levels we don't have */
-	filter_cpuid_features(c, true);
+	filter_cpuid_features(c);
 
 	/* If the model name is still unset, do table lookup. */
 	if (!c->x86_model_id[0]) {
diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c
index 306f285844aedc..e1b5f5c02c0106 100644
--- a/arch/x86/kernel/cpu/cpuid-deps.c
+++ b/arch/x86/kernel/cpu/cpuid-deps.c
@@ -150,7 +150,7 @@ cpuid_dependent_features[] = {
 	{ 0, 0 }
 };
 
-void filter_cpuid_features(struct cpuinfo_x86 *c, bool warn)
+void filter_cpuid_features(struct cpuinfo_x86 *c)
 {
 	const struct cpuid_dependent_feature *df;
 
@@ -171,8 +171,6 @@ void filter_cpuid_features(struct cpuinfo_x86 *c, bool warn)
 			continue;
 
 		clear_cpu_cap(c, df->feature);
-		if (!warn)
-			continue;
 
 		pr_warn("CPU: CPU feature " X86_CAP_FMT " disabled, no CPUID level 0x%x\n",
 			x86_cap_flag(df->feature), df->level);
-- 
2.34.3


^ permalink raw reply related	[flat|nested] 31+ messages in thread

* [PATCH v2 5/5] x86/cpuid: check for dependencies violations in CPUID and attempt to fix them
  2022-07-18 14:11 [PATCH v2 0/5] x86: cpuid: improve support for broken CPUID configurations Maxim Levitsky
                   ` (3 preceding siblings ...)
  2022-07-18 14:11 ` [PATCH v2 4/5] x86/cpuid: remove 'warn' parameter from filter_cpuid_features Maxim Levitsky
@ 2022-07-18 14:11 ` Maxim Levitsky
  2022-07-28  7:30 ` [PATCH v2 0/5] x86: cpuid: improve support for broken CPUID configurations Maxim Levitsky
  5 siblings, 0 replies; 31+ messages in thread
From: Maxim Levitsky @ 2022-07-18 14:11 UTC (permalink / raw)
  To: linux-kernel, kvm
  Cc: Pawan Gupta, Ingo Molnar, Josh Poimboeuf, Namhyung Kim,
	Tony Luck, Paolo Bonzini, H. Peter Anvin,
	Arnaldo Carvalho de Melo, Thomas Gleixner, Alexander Shishkin,
	Tim Chen, Borislav Petkov, David S. Miller, Dave Hansen,
	Chang S. Bae, Jane Malalane, Kees Cook, Kan Liang,
	Peter Zijlstra, Maxim Levitsky,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Herbert Xu, Jiri Olsa, Mark Rutland, linux-perf-users,
	open list:CRYPTO API

Due to configuration bugs, sometimes a CPU feature is disabled in CPUID,
but not features that depend on it.

For example, when one attempts to disable AVX2 but not AVX in the
guest's CPUID, the guest kernel crashes in aes-ni driver, when it
is used.

While the aes-ni driver can also be fixed to be more eager to detect this kind
of situation, it is simpler to fix this in a generic way since the kernel
has all the required info in the form of a dependency table.

Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
---
 arch/x86/kernel/cpu/cpuid-deps.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c
index e1b5f5c02c0106..376296c1f55ab2 100644
--- a/arch/x86/kernel/cpu/cpuid-deps.c
+++ b/arch/x86/kernel/cpu/cpuid-deps.c
@@ -94,6 +94,11 @@ static inline void clear_feature(struct cpuinfo_x86 *c, unsigned int feature)
 		set_bit(feature, (unsigned long *)cpu_caps_cleared);
 }
 
+static inline bool test_feature(struct cpuinfo_x86 *c, unsigned int feature)
+{
+	return test_bit(feature, (unsigned long *)c->x86_capability);
+}
+
 /* Take the capabilities and the BUG bits into account */
 #define MAX_FEATURE_BITS ((NCAPINTS + NBUGINTS) * sizeof(u32) * 8)
 
@@ -136,6 +141,10 @@ void setup_clear_cpu_cap(unsigned int feature)
  * Some CPU features depend on higher CPUID levels, which may not always
  * be available due to CPUID level capping or broken virtualization
  * software.  Add those features to this table to auto-disable them.
+ *
+ * Also due to configuration bugs, some CPUID features might be present
+ * while CPUID features that they depend on are not present,
+ * e.g a AVX2 present but AVX is not present.
  */
 struct cpuid_dependent_feature {
 	u32 feature;
@@ -153,6 +162,7 @@ cpuid_dependent_features[] = {
 void filter_cpuid_features(struct cpuinfo_x86 *c)
 {
 	const struct cpuid_dependent_feature *df;
+	const struct cpuid_dep *d;
 
 	for (df = cpuid_dependent_features; df->feature; df++) {
 
@@ -175,4 +185,16 @@ void filter_cpuid_features(struct cpuinfo_x86 *c)
 		pr_warn("CPU: CPU feature " X86_CAP_FMT " disabled, no CPUID level 0x%x\n",
 			x86_cap_flag(df->feature), df->level);
 	}
+
+	for (d = cpuid_deps; d->feature; d++) {
+
+		if (!test_feature(c, d->feature) || test_feature(c, d->depends))
+			continue;
+
+		clear_cpu_cap(c, d->feature);
+
+		pr_warn("CPU: CPU feature " X86_CAP_FMT " disabled, because it depends on "
+			X86_CAP_FMT " which is not supported in CPUID\n",
+			x86_cap_flag(d->feature), x86_cap_flag(d->depends));
+	}
 }
-- 
2.34.3


^ permalink raw reply related	[flat|nested] 31+ messages in thread

* Re: [PATCH v2 0/5] x86: cpuid: improve support for broken CPUID configurations
  2022-07-18 14:11 [PATCH v2 0/5] x86: cpuid: improve support for broken CPUID configurations Maxim Levitsky
                   ` (4 preceding siblings ...)
  2022-07-18 14:11 ` [PATCH v2 5/5] x86/cpuid: check for dependencies violations in CPUID and attempt to fix them Maxim Levitsky
@ 2022-07-28  7:30 ` Maxim Levitsky
  2022-08-01 16:05   ` Maxim Levitsky
  5 siblings, 1 reply; 31+ messages in thread
From: Maxim Levitsky @ 2022-07-28  7:30 UTC (permalink / raw)
  To: linux-kernel, kvm
  Cc: Pawan Gupta, Ingo Molnar, Josh Poimboeuf, Namhyung Kim,
	Tony Luck, Paolo Bonzini, H. Peter Anvin,
	Arnaldo Carvalho de Melo, Thomas Gleixner, Alexander Shishkin,
	Tim Chen, Borislav Petkov, David S. Miller, Dave Hansen,
	Chang S. Bae, Jane Malalane, Kees Cook, Kan Liang,
	Peter Zijlstra, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Herbert Xu, Jiri Olsa, Mark Rutland, linux-perf-users,
	open list:CRYPTO API

On Mon, 2022-07-18 at 17:11 +0300, Maxim Levitsky wrote:
> This patch series aims to harden the cpuid code against the case when
> the hypervisor exposes a broken CPUID configuration to the guest,
> in the form of having a feature disabled but not features that depend on it.
> 
> This is the more generic way to fix kernel panic in aes-ni kernel driver,
> which was triggered by CPUID configuration in which AVX is disabled but
> not AVX2.
> 
> https://lore.kernel.org/all/20211103145231.GA4485@gondor.apana.org.au/T/
> 
> This was tested by booting a guest with AVX disabled and not AVX2,
> and observing that both a warning is now printed in dmesg, and
> that avx2 is gone from /proc/cpuinfo.
> 
> V2:
> 
> I hopefully addressed all the (very good) review feedback.
> 
> Best regards,
> 	Maxim Levitsky
> 
> Maxim Levitsky (5):
>   perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap
>   x86/cpuid: refactor setup_clear_cpu_cap()/clear_cpu_cap()
>   x86/cpuid: move filter_cpuid_features to cpuid-deps.c
>   x86/cpuid: remove 'warn' parameter from filter_cpuid_features
>   x86/cpuid: check for dependencies violations in CPUID and attempt to
>     fix them
> 
>  arch/x86/events/intel/lbr.c       |  2 +-
>  arch/x86/include/asm/cpufeature.h |  1 +
>  arch/x86/kernel/cpu/common.c      | 51 +-------------------
>  arch/x86/kernel/cpu/cpuid-deps.c  | 80 +++++++++++++++++++++++++++----
>  4 files changed, 74 insertions(+), 60 deletions(-)
> 
> -- 
> 2.34.3
> 
> 
A very kind ping on these patches.

Best regards,
	Maxim Levitsky


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH v2 0/5] x86: cpuid: improve support for broken CPUID configurations
  2022-07-28  7:30 ` [PATCH v2 0/5] x86: cpuid: improve support for broken CPUID configurations Maxim Levitsky
@ 2022-08-01 16:05   ` Maxim Levitsky
  2022-08-01 16:31     ` Dave Hansen
  2022-09-19 13:43     ` Maxim Levitsky
  0 siblings, 2 replies; 31+ messages in thread
From: Maxim Levitsky @ 2022-08-01 16:05 UTC (permalink / raw)
  To: linux-kernel, kvm
  Cc: Pawan Gupta, Ingo Molnar, Josh Poimboeuf, Namhyung Kim,
	Tony Luck, Paolo Bonzini, H. Peter Anvin,
	Arnaldo Carvalho de Melo, Thomas Gleixner, Alexander Shishkin,
	Tim Chen, Borislav Petkov, David S. Miller, Dave Hansen,
	Chang S. Bae, Jane Malalane, Kees Cook, Kan Liang,
	Peter Zijlstra, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Herbert Xu, Jiri Olsa, Mark Rutland, linux-perf-users,
	open list:CRYPTO API

On Thu, 2022-07-28 at 10:30 +0300, Maxim Levitsky wrote:
> On Mon, 2022-07-18 at 17:11 +0300, Maxim Levitsky wrote:
> > This patch series aims to harden the cpuid code against the case when
> > the hypervisor exposes a broken CPUID configuration to the guest,
> > in the form of having a feature disabled but not features that depend on it.
> > 
> > This is the more generic way to fix kernel panic in aes-ni kernel driver,
> > which was triggered by CPUID configuration in which AVX is disabled but
> > not AVX2.
> > 
> > https://lore.kernel.org/all/20211103145231.GA4485@gondor.apana.org.au/T/
> > 
> > This was tested by booting a guest with AVX disabled and not AVX2,
> > and observing that both a warning is now printed in dmesg, and
> > that avx2 is gone from /proc/cpuinfo.
> > 
> > V2:
> > 
> > I hopefully addressed all the (very good) review feedback.
> > 
> > Best regards,
> > 	Maxim Levitsky
> > 
> > Maxim Levitsky (5):
> >   perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap
> >   x86/cpuid: refactor setup_clear_cpu_cap()/clear_cpu_cap()
> >   x86/cpuid: move filter_cpuid_features to cpuid-deps.c
> >   x86/cpuid: remove 'warn' parameter from filter_cpuid_features
> >   x86/cpuid: check for dependencies violations in CPUID and attempt to
> >     fix them
> > 
> >  arch/x86/events/intel/lbr.c       |  2 +-
> >  arch/x86/include/asm/cpufeature.h |  1 +
> >  arch/x86/kernel/cpu/common.c      | 51 +-------------------
> >  arch/x86/kernel/cpu/cpuid-deps.c  | 80 +++++++++++++++++++++++++++----
> >  4 files changed, 74 insertions(+), 60 deletions(-)
> > 
> > -- 
> > 2.34.3
> > 
> > 
> A very kind ping on these patches.

Another kind ping on these patches.


Best regards,
	Maxim Levitsky
> 
> Best regards,
> 	Maxim Levitsky



^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH v2 0/5] x86: cpuid: improve support for broken CPUID configurations
  2022-08-01 16:05   ` Maxim Levitsky
@ 2022-08-01 16:31     ` Dave Hansen
  2022-08-01 16:41       ` Maxim Levitsky
  2022-09-19 13:43     ` Maxim Levitsky
  1 sibling, 1 reply; 31+ messages in thread
From: Dave Hansen @ 2022-08-01 16:31 UTC (permalink / raw)
  To: Maxim Levitsky, linux-kernel, kvm
  Cc: Pawan Gupta, Ingo Molnar, Josh Poimboeuf, Namhyung Kim,
	Tony Luck, Paolo Bonzini, H. Peter Anvin,
	Arnaldo Carvalho de Melo, Thomas Gleixner, Alexander Shishkin,
	Tim Chen, Borislav Petkov, David S. Miller, Dave Hansen,
	Chang S. Bae, Jane Malalane, Kees Cook, Kan Liang,
	Peter Zijlstra, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Herbert Xu, Jiri Olsa, Mark Rutland, linux-perf-users,
	open list:CRYPTO API

On 8/1/22 09:05, Maxim Levitsky wrote:
>> A very kind ping on these patches.
> Another kind ping on these patches.

Maxim,

This series is not forgotten.  Its latest version was simply posted too
close to the merge window.  It'll get looked at in a week or two when
things calm down.

Please be patient.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH v2 0/5] x86: cpuid: improve support for broken CPUID configurations
  2022-08-01 16:31     ` Dave Hansen
@ 2022-08-01 16:41       ` Maxim Levitsky
  0 siblings, 0 replies; 31+ messages in thread
From: Maxim Levitsky @ 2022-08-01 16:41 UTC (permalink / raw)
  To: Dave Hansen, linux-kernel, kvm
  Cc: Pawan Gupta, Ingo Molnar, Josh Poimboeuf, Namhyung Kim,
	Tony Luck, Paolo Bonzini, H. Peter Anvin,
	Arnaldo Carvalho de Melo, Thomas Gleixner, Alexander Shishkin,
	Tim Chen, Borislav Petkov, David S. Miller, Dave Hansen,
	Chang S. Bae, Jane Malalane, Kees Cook, Kan Liang,
	Peter Zijlstra, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Herbert Xu, Jiri Olsa, Mark Rutland, linux-perf-users,
	open list:CRYPTO API

On Mon, 2022-08-01 at 09:31 -0700, Dave Hansen wrote:
> On 8/1/22 09:05, Maxim Levitsky wrote:
> > > A very kind ping on these patches.
> > Another kind ping on these patches.
> 
> Maxim,
> 
> This series is not forgotten.  Its latest version was simply posted too
> close to the merge window.  It'll get looked at in a week or two when
> things calm down.
> 
> Please be patient.
> 

Thanks!

Best regards,
	Maxim Levitsky


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH v2 0/5] x86: cpuid: improve support for broken CPUID configurations
  2022-08-01 16:05   ` Maxim Levitsky
  2022-08-01 16:31     ` Dave Hansen
@ 2022-09-19 13:43     ` Maxim Levitsky
  1 sibling, 0 replies; 31+ messages in thread
From: Maxim Levitsky @ 2022-09-19 13:43 UTC (permalink / raw)
  To: linux-kernel, kvm
  Cc: Pawan Gupta, Ingo Molnar, Josh Poimboeuf, Namhyung Kim,
	Tony Luck, Paolo Bonzini, H. Peter Anvin,
	Arnaldo Carvalho de Melo, Thomas Gleixner, Alexander Shishkin,
	Tim Chen, Borislav Petkov, David S. Miller, Dave Hansen,
	Chang S. Bae, Jane Malalane, Kees Cook, Kan Liang,
	Peter Zijlstra, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Herbert Xu, Jiri Olsa, Mark Rutland, linux-perf-users,
	open list:CRYPTO API

On Mon, 2022-08-01 at 19:05 +0300, Maxim Levitsky wrote:
> On Thu, 2022-07-28 at 10:30 +0300, Maxim Levitsky wrote:
> > On Mon, 2022-07-18 at 17:11 +0300, Maxim Levitsky wrote:
> > > This patch series aims to harden the cpuid code against the case when
> > > the hypervisor exposes a broken CPUID configuration to the guest,
> > > in the form of having a feature disabled but not features that depend on it.
> > > 
> > > This is the more generic way to fix kernel panic in aes-ni kernel driver,
> > > which was triggered by CPUID configuration in which AVX is disabled but
> > > not AVX2.
> > > 
> > > https://lore.kernel.org/all/20211103145231.GA4485@gondor.apana.org.au/T/
> > > 
> > > This was tested by booting a guest with AVX disabled and not AVX2,
> > > and observing that both a warning is now printed in dmesg, and
> > > that avx2 is gone from /proc/cpuinfo.
> > > 
> > > V2:
> > > 
> > > I hopefully addressed all the (very good) review feedback.
> > > 
> > > Best regards,
> > > 	Maxim Levitsky
> > > 
> > > Maxim Levitsky (5):
> > >   perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap
> > >   x86/cpuid: refactor setup_clear_cpu_cap()/clear_cpu_cap()
> > >   x86/cpuid: move filter_cpuid_features to cpuid-deps.c
> > >   x86/cpuid: remove 'warn' parameter from filter_cpuid_features
> > >   x86/cpuid: check for dependencies violations in CPUID and attempt to
> > >     fix them
> > > 
> > >  arch/x86/events/intel/lbr.c       |  2 +-
> > >  arch/x86/include/asm/cpufeature.h |  1 +
> > >  arch/x86/kernel/cpu/common.c      | 51 +-------------------
> > >  arch/x86/kernel/cpu/cpuid-deps.c  | 80 +++++++++++++++++++++++++++----
> > >  4 files changed, 74 insertions(+), 60 deletions(-)
> > > 
> > > -- 
> > > 2.34.3
> > > 
> > > 
> > A very kind ping on these patches.
> 
> Another kind ping on these patches.

Another very gentle ping on these patches.

Best regards,
	Maxim Levitsky
> 
> 
> Best regards,
> 	Maxim Levitsky
> > Best regards,
> > 	Maxim Levitsky



^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH v2 1/5] perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap
  2022-07-18 14:11 ` [PATCH v2 1/5] perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap Maxim Levitsky
@ 2022-09-19 14:31   ` Borislav Petkov
  2022-09-20  8:20     ` Maxim Levitsky
  2022-10-20 15:17   ` [tip: x86/urgent] perf/x86/intel/lbr: Use setup_clear_cpu_cap() instead of clear_cpu_cap() tip-bot2 for Maxim Levitsky
  1 sibling, 1 reply; 31+ messages in thread
From: Borislav Petkov @ 2022-09-19 14:31 UTC (permalink / raw)
  To: Maxim Levitsky
  Cc: linux-kernel, kvm, Pawan Gupta, Ingo Molnar, Josh Poimboeuf,
	Namhyung Kim, Tony Luck, Paolo Bonzini, H. Peter Anvin,
	Arnaldo Carvalho de Melo, Thomas Gleixner, Alexander Shishkin,
	Tim Chen, David S. Miller, Dave Hansen, Chang S. Bae,
	Jane Malalane, Kees Cook, Kan Liang, Peter Zijlstra,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Herbert Xu, Jiri Olsa, Mark Rutland, linux-perf-users,
	open list:CRYPTO API

On Mon, Jul 18, 2022 at 05:11:19PM +0300, Maxim Levitsky wrote:
> clear_cpu_cap(&boot_cpu_data) is very similar to setup_clear_cpu_cap
> except that the latter also sets a bit in 'cpu_caps_cleared' which
> later clears the same cap in secondary cpus, which is likely
> what is meant here.
> 
> Fixes: 47125db27e47 ("perf/x86/intel/lbr: Support Architectural LBR")
> 
> Reviewed-by: Kan Liang <kan.liang@linux.intel.com>
> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
> ---
>  arch/x86/events/intel/lbr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c
> index 13179f31fe10fa..b08715172309a7 100644
> --- a/arch/x86/events/intel/lbr.c
> +++ b/arch/x86/events/intel/lbr.c
> @@ -1860,7 +1860,7 @@ void __init intel_pmu_arch_lbr_init(void)
>  	return;
>  
>  clear_arch_lbr:
> -	clear_cpu_cap(&boot_cpu_data, X86_FEATURE_ARCH_LBR);
> +	setup_clear_cpu_cap(X86_FEATURE_ARCH_LBR);

setup_clear_cpu_cap() has a very specific purpose - see
apply_forced_caps().

This whole call sequence is an early_initcall() which is way after the
whole CPU features picking apart happens.

So what is actually this fixing?

-- 
Regards/Gruss,
    Boris.

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

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH v2 1/5] perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap
  2022-09-19 14:31   ` Borislav Petkov
@ 2022-09-20  8:20     ` Maxim Levitsky
  2022-09-26 13:12       ` Borislav Petkov
  0 siblings, 1 reply; 31+ messages in thread
From: Maxim Levitsky @ 2022-09-20  8:20 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: linux-kernel, kvm, Pawan Gupta, Ingo Molnar, Josh Poimboeuf,
	Namhyung Kim, Tony Luck, Paolo Bonzini, H. Peter Anvin,
	Arnaldo Carvalho de Melo, Thomas Gleixner, Alexander Shishkin,
	Tim Chen, David S. Miller, Dave Hansen, Chang S. Bae,
	Jane Malalane, Kees Cook, Kan Liang, Peter Zijlstra,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Herbert Xu, Jiri Olsa, Mark Rutland, linux-perf-users,
	open list:CRYPTO API

On Mon, 2022-09-19 at 16:31 +0200, Borislav Petkov wrote:
> On Mon, Jul 18, 2022 at 05:11:19PM +0300, Maxim Levitsky wrote:
> > clear_cpu_cap(&boot_cpu_data) is very similar to setup_clear_cpu_cap
> > except that the latter also sets a bit in 'cpu_caps_cleared' which
> > later clears the same cap in secondary cpus, which is likely
> > what is meant here.
> > 
> > Fixes: 47125db27e47 ("perf/x86/intel/lbr: Support Architectural LBR")
> > 
> > Reviewed-by: Kan Liang <kan.liang@linux.intel.com>
> > Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
> > ---
> >  arch/x86/events/intel/lbr.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c
> > index 13179f31fe10fa..b08715172309a7 100644
> > --- a/arch/x86/events/intel/lbr.c
> > +++ b/arch/x86/events/intel/lbr.c
> > @@ -1860,7 +1860,7 @@ void __init intel_pmu_arch_lbr_init(void)
> >         return;
> >  
> >  clear_arch_lbr:
> > -       clear_cpu_cap(&boot_cpu_data, X86_FEATURE_ARCH_LBR);
> > +       setup_clear_cpu_cap(X86_FEATURE_ARCH_LBR);
> 
> setup_clear_cpu_cap() has a very specific purpose - see
> apply_forced_caps().
> 
> This whole call sequence is an early_initcall() which is way after the
> whole CPU features picking apart happens.
> 
> So what is actually this fixing?
> 

If I understand that correctly, the difference between clear_cpu_cap and setup_clear_cpu_cap
is that setup_clear_cpu_cap should be called early when only the boot cpu is running and it 
 
1. works on 'boot_cpu_data' which represents the boot cpu.
2. sets a bit in 'cpu_caps_cleared' which are later applied to all CPUs, including these that are hotplugged.
 
On the other hand the clear_cpu_cap just affects the given 'struct cpuinfo_x86'.
 
Call of 'clear_cpu_cap(&boot_cpu_data, X86_FEATURE_ARCH_LBR)' is weird since it still affects 'boot_cpu_data'
but doesn't affect 'cpu_caps_cleared'
 
I assumed that this was a mistake and the intention was to disable the feature on all CPUs.
 
I need this patch because in the next patch, I change the clear_cpu_cap such as it detects being
called on boot_cpu_data and in this case also clears bits in 'cpu_caps_cleared', thus
while this patch does introduce a functional change, the next patch doesn't since this is the only
place where clear_cpu_cap is called explicitly on 'boot_cpu_data'
 
 
I do now notice that initcalls are run after smp is initialized, which means that this code doesn't really
disable the CPUID feature on all CPUs at all.
 
Maybe we can drop the call instead, which does seem to be wrong?

Best regards,
	Maxim Levitsky





^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH v2 1/5] perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap
  2022-09-20  8:20     ` Maxim Levitsky
@ 2022-09-26 13:12       ` Borislav Petkov
  2022-09-28 10:49         ` Maxim Levitsky
  0 siblings, 1 reply; 31+ messages in thread
From: Borislav Petkov @ 2022-09-26 13:12 UTC (permalink / raw)
  To: Maxim Levitsky
  Cc: linux-kernel, kvm, Pawan Gupta, Ingo Molnar, Josh Poimboeuf,
	Namhyung Kim, Tony Luck, Paolo Bonzini, H. Peter Anvin,
	Arnaldo Carvalho de Melo, Thomas Gleixner, Alexander Shishkin,
	Tim Chen, David S. Miller, Dave Hansen, Chang S. Bae,
	Jane Malalane, Kees Cook, Kan Liang, Peter Zijlstra,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Herbert Xu, Jiri Olsa, Mark Rutland, linux-perf-users,
	open list:CRYPTO API

On Tue, Sep 20, 2022 at 11:20:47AM +0300, Maxim Levitsky wrote:
> If I understand that correctly, the difference between clear_cpu_cap and setup_clear_cpu_cap
> is that setup_clear_cpu_cap should be called early when only the boot cpu is running and it 
>
> 1. works on 'boot_cpu_data' which represents the boot cpu.
> 2. sets a bit in 'cpu_caps_cleared' which are later applied to all CPUs, including these that are hotplugged.

Yes.

> On the other hand the clear_cpu_cap just affects the given 'struct cpuinfo_x86'.

Yes.

> Call of 'clear_cpu_cap(&boot_cpu_data, X86_FEATURE_ARCH_LBR)' is weird since it still affects 'boot_cpu_data'
> but doesn't affect 'cpu_caps_cleared'

Yes.

> I assumed that this was a mistake and the intention was to disable the feature on all CPUs.

peterz says yes.

> I need this patch because in the next patch, I change the clear_cpu_cap such as it detects being
> called on boot_cpu_data and in this case also clears bits in 'cpu_caps_cleared', thus
> while this patch does introduce a functional change, the next patch doesn't since this is the only
> place where clear_cpu_cap is called explicitly on 'boot_cpu_data'

This is not needed - this patch doing setup_clear_cpu_cap() should suffice.

But, there must be something you're fixing with this. Which is it? Some
weird virt config?

> I do now notice that initcalls are run after smp is initialized, which
> means that this code doesn't really disable the CPUID feature on all
> CPUs at all.

Well, not exactly. There's do_pre_smp_calls() which is where the
early_initcall() thing is run.

So setup_clear_cpu_cap() will make sure that the feature bit is cleared
when the APs come online.

Do you have a virt configuration where you can test this case where the
feature flag is clear on all CPUs when it fails?

I.e., "arch_lbr" will disappear in /proc/cpuinfo completely.

Thx.

-- 
Regards/Gruss,
    Boris.

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

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH v2 1/5] perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap
  2022-09-26 13:12       ` Borislav Petkov
@ 2022-09-28 10:49         ` Maxim Levitsky
  2022-10-20  8:59           ` Borislav Petkov
  0 siblings, 1 reply; 31+ messages in thread
From: Maxim Levitsky @ 2022-09-28 10:49 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: linux-kernel, kvm, Pawan Gupta, Ingo Molnar, Josh Poimboeuf,
	Namhyung Kim, Tony Luck, Paolo Bonzini, H. Peter Anvin,
	Arnaldo Carvalho de Melo, Thomas Gleixner, Alexander Shishkin,
	Tim Chen, David S. Miller, Dave Hansen, Chang S. Bae,
	Jane Malalane, Kees Cook, Kan Liang, Peter Zijlstra,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Herbert Xu, Jiri Olsa, Mark Rutland, linux-perf-users,
	open list:CRYPTO API

On Mon, 2022-09-26 at 15:12 +0200, Borislav Petkov wrote:
> On Tue, Sep 20, 2022 at 11:20:47AM +0300, Maxim Levitsky wrote:
> > If I understand that correctly, the difference between clear_cpu_cap and setup_clear_cpu_cap
> > is that setup_clear_cpu_cap should be called early when only the boot cpu is running and it 
> > 
> > 1. works on 'boot_cpu_data' which represents the boot cpu.
> > 2. sets a bit in 'cpu_caps_cleared' which are later applied to all CPUs, including these that are hotplugged.
> 
> Yes.
> 
> > On the other hand the clear_cpu_cap just affects the given 'struct cpuinfo_x86'.
> 
> Yes.
> 
> > Call of 'clear_cpu_cap(&boot_cpu_data, X86_FEATURE_ARCH_LBR)' is weird since it still affects 'boot_cpu_data'
> > but doesn't affect 'cpu_caps_cleared'
> 
> Yes.
> 
> > I assumed that this was a mistake and the intention was to disable the feature on all CPUs.
> 
> peterz says yes.
> 
> > I need this patch because in the next patch, I change the clear_cpu_cap such as it detects being
> > called on boot_cpu_data and in this case also clears bits in 'cpu_caps_cleared', thus
> > while this patch does introduce a functional change, the next patch doesn't since this is the only
> > place where clear_cpu_cap is called explicitly on 'boot_cpu_data'
> 
> This is not needed - this patch doing setup_clear_cpu_cap() should suffice.
> 
> But, there must be something you're fixing with this. Which is it? Some
> weird virt config?

Patches 1-3 don't fix anything - these are just refactoring to make the code simplier.

This particular patch is done to enable the refactoring in the next patch by removing an
(hopefully broken) outlier.


Patch 4 is small fix in the sense that it allows the warning from the current cpuid filtering code
to be seen (it is supressed in early code, but then it doesn't usually happen again, so no warning
is printed at all)

Patch 5 is the main fix - it  makes the kernel to be tolerant to a broken CPUID config 
(coming hopefully from hypervisor),
where you have a feature (AVX2 in my case) but not a feature on which this feature depends (AVX).


> 
> > I do now notice that initcalls are run after smp is initialized, which
> > means that this code doesn't really disable the CPUID feature on all
> > CPUs at all.
> 
> Well, not exactly. There's do_pre_smp_calls() which is where the
> early_initcall() thing is run.


Aha! I was reading the 'do_initcalls()' code and thought that it
goes over all initcalls.

note that it turns out that this function is called 'do_pre_smp_initcalls()'.

> 
> So setup_clear_cpu_cap() will make sure that the feature bit is cleared
> when the APs come online.
> 
> Do you have a virt configuration where you can test this case where the
> feature flag is clear on all CPUs when it fails?

This needs the arch lbrs which aren't yet supported by KVM (there are patches
on the mailing list), plus I need a hardware which supportes them, of which
I don't know even if intel released any yet.

I can hack the code/KVM though to simulate enough of it to see if this failback
happens.

Besides that, anything else I should do to to see that patch series merged?

Thanks,
Best regards,
	Maxim Levitsky

> 
> I.e., "arch_lbr" will disappear in /proc/cpuinfo completely.
> 
> Thx.
> 



^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH v2 1/5] perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap
  2022-09-28 10:49         ` Maxim Levitsky
@ 2022-10-20  8:59           ` Borislav Petkov
  2022-10-20  9:05             ` Herbert Xu
                               ` (2 more replies)
  0 siblings, 3 replies; 31+ messages in thread
From: Borislav Petkov @ 2022-10-20  8:59 UTC (permalink / raw)
  To: Maxim Levitsky
  Cc: linux-kernel, kvm, Pawan Gupta, Ingo Molnar, Josh Poimboeuf,
	Namhyung Kim, Tony Luck, Paolo Bonzini, H. Peter Anvin,
	Arnaldo Carvalho de Melo, Thomas Gleixner, Alexander Shishkin,
	Tim Chen, David S. Miller, Dave Hansen, Chang S. Bae,
	Jane Malalane, Kees Cook, Kan Liang, Peter Zijlstra,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Herbert Xu, Jiri Olsa, Mark Rutland, linux-perf-users,
	open list:CRYPTO API

On Wed, Sep 28, 2022 at 01:49:34PM +0300, Maxim Levitsky wrote:
> Patch 5 is the main fix - it makes the kernel to be tolerant to a
> broken CPUID config (coming hopefully from hypervisor), where you have
> a feature (AVX2 in my case) but not a feature on which this feature
> depends (AVX).

I really really don't like it when people are fixing the wrong thing.

Why does the kernel need to get fixed when something else can't get its
CPUID dependencies straight? I don't even want to know why something
would set AVX2 without AVX?!?!

Srsly.

Some of your other bits look sensible and I'd take a deeper look but
this does not make any sense. This is a hypervisor problem - not a
kernel one.

Thx.

-- 
Regards/Gruss,
    Boris.

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

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH v2 1/5] perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap
  2022-10-20  8:59           ` Borislav Petkov
@ 2022-10-20  9:05             ` Herbert Xu
  2022-10-20 10:21               ` Maxim Levitsky
  2022-10-22 21:08             ` H. Peter Anvin
  2022-11-02 13:40             ` Paolo Bonzini
  2 siblings, 1 reply; 31+ messages in thread
From: Herbert Xu @ 2022-10-20  9:05 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Maxim Levitsky, linux-kernel, kvm, Pawan Gupta, Ingo Molnar,
	Josh Poimboeuf, Namhyung Kim, Tony Luck, Paolo Bonzini,
	H. Peter Anvin, Arnaldo Carvalho de Melo, Thomas Gleixner,
	Alexander Shishkin, Tim Chen, David S. Miller, Dave Hansen,
	Chang S. Bae, Jane Malalane, Kees Cook, Kan Liang,
	Peter Zijlstra, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Herbert Xu, Jiri Olsa, Mark Rutland, linux-perf-users,
	open list:CRYPTO API

On Thu, Oct 20, 2022 at 10:59:48AM +0200, Borislav Petkov wrote:
>
> I really really don't like it when people are fixing the wrong thing.
> 
> Why does the kernel need to get fixed when something else can't get its
> CPUID dependencies straight? I don't even want to know why something
> would set AVX2 without AVX?!?!

That's exactly what I said when this was first reported to me as
a crypto bug :)

Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH v2 1/5] perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap
  2022-10-20  9:05             ` Herbert Xu
@ 2022-10-20 10:21               ` Maxim Levitsky
  2022-10-20 11:13                 ` Borislav Petkov
  0 siblings, 1 reply; 31+ messages in thread
From: Maxim Levitsky @ 2022-10-20 10:21 UTC (permalink / raw)
  To: Herbert Xu, Borislav Petkov
  Cc: linux-kernel, kvm, Pawan Gupta, Ingo Molnar, Josh Poimboeuf,
	Namhyung Kim, Tony Luck, Paolo Bonzini, H. Peter Anvin,
	Arnaldo Carvalho de Melo, Thomas Gleixner, Alexander Shishkin,
	Tim Chen, David S. Miller, Dave Hansen, Chang S. Bae,
	Jane Malalane, Kees Cook, Kan Liang, Peter Zijlstra,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Jiri Olsa, Mark Rutland, linux-perf-users, open list:CRYPTO API

On Thu, 2022-10-20 at 17:05 +0800, Herbert Xu wrote:
> On Thu, Oct 20, 2022 at 10:59:48AM +0200, Borislav Petkov wrote:
> > I really really don't like it when people are fixing the wrong thing.
> > 
> > Why does the kernel need to get fixed when something else can't get its
> > CPUID dependencies straight? I don't even want to know why something
> > would set AVX2 without AVX?!?!
> 
> That's exactly what I said when this was first reported to me as
> a crypto bug :)

I agree with you, however this patch series is just refactoring/hardening of the kernel -
if the kernel can avoid crashing - why not.

Of course the hypervisor should not present such broken configurations to the guest - 
in fact the guest kernel can't fix this - guest userspace will still see wrong CPUID and
can still crash.

TL;DR - this patch series is not intended to workaround a broken hypervisor and such,
it is just a hardening against misconfiguration.

Best regards,
	Maxim Levitsky


> 
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> 



^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH v2 1/5] perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap
  2022-10-20 10:21               ` Maxim Levitsky
@ 2022-10-20 11:13                 ` Borislav Petkov
  0 siblings, 0 replies; 31+ messages in thread
From: Borislav Petkov @ 2022-10-20 11:13 UTC (permalink / raw)
  To: Maxim Levitsky
  Cc: Herbert Xu, linux-kernel, kvm, Pawan Gupta, Ingo Molnar,
	Josh Poimboeuf, Namhyung Kim, Tony Luck, Paolo Bonzini,
	H. Peter Anvin, Arnaldo Carvalho de Melo, Thomas Gleixner,
	Alexander Shishkin, Tim Chen, David S. Miller, Dave Hansen,
	Chang S. Bae, Jane Malalane, Kees Cook, Kan Liang,
	Peter Zijlstra, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Jiri Olsa, Mark Rutland, linux-perf-users, open list:CRYPTO API

On Thu, Oct 20, 2022 at 01:21:30PM +0300, Maxim Levitsky wrote:
> I agree with you, however this patch series is just
> refactoring/hardening of the kernel - if the kernel can avoid crashing
> - why not.

Because we're already drowning in patches which are trying to fix real
problems. If we open the floodgates on alleged hardening just because
some other part of the stack is misbehaving, there'll be no end of it.

Thx.

-- 
Regards/Gruss,
    Boris.

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

^ permalink raw reply	[flat|nested] 31+ messages in thread

* [tip: x86/urgent] perf/x86/intel/lbr: Use setup_clear_cpu_cap() instead of clear_cpu_cap()
  2022-07-18 14:11 ` [PATCH v2 1/5] perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap Maxim Levitsky
  2022-09-19 14:31   ` Borislav Petkov
@ 2022-10-20 15:17   ` tip-bot2 for Maxim Levitsky
  1 sibling, 0 replies; 31+ messages in thread
From: tip-bot2 for Maxim Levitsky @ 2022-10-20 15:17 UTC (permalink / raw)
  To: linux-tip-commits
  Cc: Maxim Levitsky, Peter Zijlstra (Intel), Kan Liang, x86, linux-kernel

The following commit has been merged into the x86/urgent branch of tip:

Commit-ID:     b329f5ddc9ce4b622d9c7aaf5c6df4de52caf91a
Gitweb:        https://git.kernel.org/tip/b329f5ddc9ce4b622d9c7aaf5c6df4de52caf91a
Author:        Maxim Levitsky <mlevitsk@redhat.com>
AuthorDate:    Mon, 18 Jul 2022 17:11:19 +03:00
Committer:     Peter Zijlstra <peterz@infradead.org>
CommitterDate: Thu, 20 Oct 2022 17:10:28 +02:00

perf/x86/intel/lbr: Use setup_clear_cpu_cap() instead of clear_cpu_cap()

clear_cpu_cap(&boot_cpu_data) is very similar to setup_clear_cpu_cap()
except that the latter also sets a bit in 'cpu_caps_cleared' which
later clears the same cap in secondary cpus, which is likely what is
meant here.

Fixes: 47125db27e47 ("perf/x86/intel/lbr: Support Architectural LBR")
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Kan Liang <kan.liang@linux.intel.com>
Link: https://lkml.kernel.org/r/20220718141123.136106-2-mlevitsk@redhat.com
---
 arch/x86/events/intel/lbr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c
index 4fce1a4..8259d72 100644
--- a/arch/x86/events/intel/lbr.c
+++ b/arch/x86/events/intel/lbr.c
@@ -1596,7 +1596,7 @@ void __init intel_pmu_arch_lbr_init(void)
 	return;
 
 clear_arch_lbr:
-	clear_cpu_cap(&boot_cpu_data, X86_FEATURE_ARCH_LBR);
+	setup_clear_cpu_cap(X86_FEATURE_ARCH_LBR);
 }
 
 /**

^ permalink raw reply related	[flat|nested] 31+ messages in thread

* Re: [PATCH v2 2/5] x86/cpuid: refactor setup_clear_cpu_cap()/clear_cpu_cap()
  2022-07-18 14:11 ` [PATCH v2 2/5] x86/cpuid: refactor setup_clear_cpu_cap()/clear_cpu_cap() Maxim Levitsky
@ 2022-10-21 16:19   ` Borislav Petkov
  2022-11-07 19:10     ` Borislav Petkov
  0 siblings, 1 reply; 31+ messages in thread
From: Borislav Petkov @ 2022-10-21 16:19 UTC (permalink / raw)
  To: Maxim Levitsky
  Cc: linux-kernel, kvm, Pawan Gupta, Ingo Molnar, Josh Poimboeuf,
	Namhyung Kim, Tony Luck, Paolo Bonzini, H. Peter Anvin,
	Arnaldo Carvalho de Melo, Thomas Gleixner, Alexander Shishkin,
	Tim Chen, David S. Miller, Dave Hansen, Chang S. Bae,
	Jane Malalane, Kees Cook, Kan Liang, Peter Zijlstra,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Herbert Xu, Jiri Olsa, Mark Rutland, linux-perf-users,
	open list:CRYPTO API

On Mon, Jul 18, 2022 at 05:11:20PM +0300, Maxim Levitsky wrote:
> Currently setup_clear_cpu_cap passes NULL 'struct cpuinfo_x86*'
> to clear_cpu_cap to indicate that capability should be cleared from boot_cpu_data.
> 
> Later that is used in clear_feature to do recursive call to
> clear_cpu_cap together with clearing the feature bit from 'cpu_caps_cleared'
> 
> Remove that code and just call the do_clear_cpu_cap on boot_cpu_data directly
> from the setup_clear_cpu_cap.
> 
> The only functional change this introduces is that now calling clear_cpu_cap
> explicitly on boot_cpu_data also sets the bits in cpu_caps_cleared,
> which is the only thing that makes sense anyway.
> 
> All callers of both functions were checked for this and fixed.

Change looks ok. What I can't grok is this sentence: what was checked
and fixed where?

What does need fixing and why?

Thx.

-- 
Regards/Gruss,
    Boris.

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

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH v2 1/5] perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap
  2022-10-20  8:59           ` Borislav Petkov
  2022-10-20  9:05             ` Herbert Xu
@ 2022-10-22 21:08             ` H. Peter Anvin
  2022-11-02 13:40             ` Paolo Bonzini
  2 siblings, 0 replies; 31+ messages in thread
From: H. Peter Anvin @ 2022-10-22 21:08 UTC (permalink / raw)
  To: Borislav Petkov, Maxim Levitsky
  Cc: linux-kernel, kvm, Pawan Gupta, Ingo Molnar, Josh Poimboeuf,
	Namhyung Kim, Tony Luck, Paolo Bonzini, Arnaldo Carvalho de Melo,
	Thomas Gleixner, Alexander Shishkin, Tim Chen, David S. Miller,
	Dave Hansen, Chang S. Bae, Jane Malalane, Kees Cook, Kan Liang,
	Peter Zijlstra, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Herbert Xu, Jiri Olsa, Mark Rutland, linux-perf-users,
	open list:CRYPTO API

On October 20, 2022 1:59:48 AM PDT, Borislav Petkov <bp@alien8.de> wrote:
>On Wed, Sep 28, 2022 at 01:49:34PM +0300, Maxim Levitsky wrote:
>> Patch 5 is the main fix - it makes the kernel to be tolerant to a
>> broken CPUID config (coming hopefully from hypervisor), where you have
>> a feature (AVX2 in my case) but not a feature on which this feature
>> depends (AVX).
>
>I really really don't like it when people are fixing the wrong thing.
>
>Why does the kernel need to get fixed when something else can't get its
>CPUID dependencies straight? I don't even want to know why something
>would set AVX2 without AVX?!?!
>
>Srsly.
>
>Some of your other bits look sensible and I'd take a deeper look but
>this does not make any sense. This is a hypervisor problem - not a
>kernel one.
>
>Thx.
>

Yes, this is utterly nonsensical and it will break user space applications left, right, and center.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH v2 1/5] perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap
  2022-10-20  8:59           ` Borislav Petkov
  2022-10-20  9:05             ` Herbert Xu
  2022-10-22 21:08             ` H. Peter Anvin
@ 2022-11-02 13:40             ` Paolo Bonzini
  2022-11-02 14:27               ` Elliott, Robert (Servers)
  2 siblings, 1 reply; 31+ messages in thread
From: Paolo Bonzini @ 2022-11-02 13:40 UTC (permalink / raw)
  To: Borislav Petkov, Maxim Levitsky
  Cc: linux-kernel, kvm, Pawan Gupta, Ingo Molnar, Josh Poimboeuf,
	Namhyung Kim, Tony Luck, H. Peter Anvin,
	Arnaldo Carvalho de Melo, Thomas Gleixner, Alexander Shishkin,
	Tim Chen, David S. Miller, Dave Hansen, Chang S. Bae,
	Jane Malalane, Kees Cook, Kan Liang, Peter Zijlstra,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Herbert Xu, Jiri Olsa, Mark Rutland, linux-perf-users,
	open list:CRYPTO API

On 10/20/22 10:59, Borislav Petkov wrote:
> On Wed, Sep 28, 2022 at 01:49:34PM +0300, Maxim Levitsky wrote:
>> Patch 5 is the main fix - it makes the kernel to be tolerant to a
>> broken CPUID config (coming hopefully from hypervisor), where you have
>> a feature (AVX2 in my case) but not a feature on which this feature
>> depends (AVX).
> 
> I really really don't like it when people are fixing the wrong thing.
> 
> Why does the kernel need to get fixed when something else can't get its
> CPUID dependencies straight? I don't even want to know why something
> would set AVX2 without AVX?!?!

Users do so because they just "disable AVX" (e.g. in QEMU -cpu 
host,-avx) and that removes the AVX bit.  Userspace didn't bother to 
implement the whole set of CPUID bit dependencies for AVX because:

1) Intel is adding AVX features every other week and probably half the 
time people would forget to add the dependency

2) anyway you absolutely need to check XCR0 before using AVX, which in 
the kernel is done using cpu_has_xfeatures(XFEATURE_MASK_YMM), and 
userspace *does* remove the XSAVE state from 0Dh leaf if you remove AVX.

(2) in particular holds even on bare metal.  The kernel bug here is that 
X86_FEATURE_AVX only tells you if the instructions are _present_, not if 
they are _usable_.   Indeed, the XCR0 check is present for all other 
files in arch/x86/crypto, either instead or in addition to 
boot_cpu_has(X86_FEATURE_AVX).

Maxim had sent a patch about a year ago to do it in aesni-intel-glue.c 
but Dave told him to fix the dependencies instead 
(https://lore.kernel.org/all/20211103124614.499580-1-mlevitsk@redhat.com/). 
  What do you think of applying that patch instead?

Thanks,

Paolo


^ permalink raw reply	[flat|nested] 31+ messages in thread

* RE: [PATCH v2 1/5] perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap
  2022-11-02 13:40             ` Paolo Bonzini
@ 2022-11-02 14:27               ` Elliott, Robert (Servers)
  2022-11-02 16:23                 ` H. Peter Anvin
  2022-11-03 13:30                 ` Paolo Bonzini
  0 siblings, 2 replies; 31+ messages in thread
From: Elliott, Robert (Servers) @ 2022-11-02 14:27 UTC (permalink / raw)
  To: Paolo Bonzini, Borislav Petkov, Maxim Levitsky
  Cc: linux-kernel, kvm, Pawan Gupta, Ingo Molnar, Josh Poimboeuf,
	Namhyung Kim, Tony Luck, H. Peter Anvin,
	Arnaldo Carvalho de Melo, Thomas Gleixner, Alexander Shishkin,
	Tim Chen, David S. Miller, Dave Hansen, Chang S. Bae,
	Jane Malalane, Kees Cook, Kan Liang, Peter Zijlstra,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Herbert Xu, Jiri Olsa, Mark Rutland, linux-perf-users,
	open list:CRYPTO API


> From: Paolo Bonzini <pbonzini@redhat.com>
...
> (2) in particular holds even on bare metal.  The kernel bug here is that
> X86_FEATURE_AVX only tells you if the instructions are _present_, not if
> they are _usable_.   Indeed, the XCR0 check is present for all other
> files in arch/x86/crypto, either instead or in addition to
> boot_cpu_has(X86_FEATURE_AVX).
> 
> Maxim had sent a patch about a year ago to do it in aesni-intel-glue.c
> but Dave told him to fix the dependencies instead
> (https://lore.kernel.org/all/20211103124614.499580-1-
> mlevitsk@redhat.com/).
>   What do you think of applying that patch instead?

Most of the x86 crypto modules using X86_FEATURE_AVX do check
	cpu_has_xfeatures(XFEATURE_MASK_YMM, ...

so it's probably prudent to add it to the rest (or remove it everywhere
if it is not needed).

1. Currently checking XSAVE YMM:
  aria_aesni_avx_glue
  blake2s-glue
  camellia_aesni_avx2_glue	camellia_aesni_avx_glue
  cast5_avx_glue		cast6_avx_glue
  chacha_glue
  poly1305_glue
  serpent_avx2_glue		serpent_avx_glue
  sha1_ssse3_glue		sha256_ssse3_glue	sha512_ssse3_glue
  sm3_avx_glue
  sm4_aesni_avx2_glue	sm4_aesni_avx_glue
  twofish_avx_glue

Currently not checking XSAVE YMM:
  aesni-intel_glue
  curve25519-x86_64
  nhpoly1305-avx2-glue
  polyval-clmulni_glue

2. Similarly, modules using X86_FEATURE_AVX512F, X86_FEATURE_AVXX512VL
and/or X86_FEATURE_AVX512BW probably need to check XFEATURE_MASK_AVX512:

Currently checking XSAVE AVX512:
  blake2s-glue
  poly1305_glue

Currently not checking XSAVE AVX512:
  chacha_glue

3. Similarly, modules using X86_FEATURE_XMM2 probably need to
check XFEATURE_MASK_SSE:

Currently checking XSAVE SSE:
  aegis128-aesni-glue 

Current not checking XSAVE SSE:
  nhpoly1305-sse2_glue
  serpent_sse2_glue



^ permalink raw reply	[flat|nested] 31+ messages in thread

* RE: [PATCH v2 1/5] perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap
  2022-11-02 14:27               ` Elliott, Robert (Servers)
@ 2022-11-02 16:23                 ` H. Peter Anvin
  2022-11-02 18:19                   ` H. Peter Anvin
  2022-11-03 13:26                   ` Paolo Bonzini
  2022-11-03 13:30                 ` Paolo Bonzini
  1 sibling, 2 replies; 31+ messages in thread
From: H. Peter Anvin @ 2022-11-02 16:23 UTC (permalink / raw)
  To: Elliott, Robert (Servers),
	Paolo Bonzini, Borislav Petkov, Maxim Levitsky
  Cc: linux-kernel, kvm, Pawan Gupta, Ingo Molnar, Josh Poimboeuf,
	Namhyung Kim, Tony Luck, Arnaldo Carvalho de Melo,
	Thomas Gleixner, Alexander Shishkin, Tim Chen, David S. Miller,
	Dave Hansen, Chang S. Bae, Jane Malalane, Kees Cook, Kan Liang,
	Peter Zijlstra, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Herbert Xu, Jiri Olsa, Mark Rutland, linux-perf-users,
	open list:CRYPTO API

On November 2, 2022 7:27:52 AM PDT, "Elliott, Robert (Servers)" <elliott@hpe.com> wrote:
>
>> From: Paolo Bonzini <pbonzini@redhat.com>
>...
>> (2) in particular holds even on bare metal.  The kernel bug here is that
>> X86_FEATURE_AVX only tells you if the instructions are _present_, not if
>> they are _usable_.   Indeed, the XCR0 check is present for all other
>> files in arch/x86/crypto, either instead or in addition to
>> boot_cpu_has(X86_FEATURE_AVX).
>> 
>> Maxim had sent a patch about a year ago to do it in aesni-intel-glue.c
>> but Dave told him to fix the dependencies instead
>> (https://lore.kernel.org/all/20211103124614.499580-1-
>> mlevitsk@redhat.com/).
>>   What do you think of applying that patch instead?
>
>Most of the x86 crypto modules using X86_FEATURE_AVX do check
>	cpu_has_xfeatures(XFEATURE_MASK_YMM, ...
>
>so it's probably prudent to add it to the rest (or remove it everywhere
>if it is not needed).
>
>1. Currently checking XSAVE YMM:
>  aria_aesni_avx_glue
>  blake2s-glue
>  camellia_aesni_avx2_glue	camellia_aesni_avx_glue
>  cast5_avx_glue		cast6_avx_glue
>  chacha_glue
>  poly1305_glue
>  serpent_avx2_glue		serpent_avx_glue
>  sha1_ssse3_glue		sha256_ssse3_glue	sha512_ssse3_glue
>  sm3_avx_glue
>  sm4_aesni_avx2_glue	sm4_aesni_avx_glue
>  twofish_avx_glue
>
>Currently not checking XSAVE YMM:
>  aesni-intel_glue
>  curve25519-x86_64
>  nhpoly1305-avx2-glue
>  polyval-clmulni_glue
>
>2. Similarly, modules using X86_FEATURE_AVX512F, X86_FEATURE_AVXX512VL
>and/or X86_FEATURE_AVX512BW probably need to check XFEATURE_MASK_AVX512:
>
>Currently checking XSAVE AVX512:
>  blake2s-glue
>  poly1305_glue
>
>Currently not checking XSAVE AVX512:
>  chacha_glue
>
>3. Similarly, modules using X86_FEATURE_XMM2 probably need to
>check XFEATURE_MASK_SSE:
>
>Currently checking XSAVE SSE:
>  aegis128-aesni-glue 
>
>Current not checking XSAVE SSE:
>  nhpoly1305-sse2_glue
>  serpent_sse2_glue
>
>
>

We have a dependency system for CPUID features. If you are going to do this (as opposed to "fixing" this in Qemu or just saying "don't do that, it isn't a valid hardware configuration."

^ permalink raw reply	[flat|nested] 31+ messages in thread

* RE: [PATCH v2 1/5] perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap
  2022-11-02 16:23                 ` H. Peter Anvin
@ 2022-11-02 18:19                   ` H. Peter Anvin
  2022-11-02 19:14                     ` Elliott, Robert (Servers)
  2022-11-03 13:26                   ` Paolo Bonzini
  1 sibling, 1 reply; 31+ messages in thread
From: H. Peter Anvin @ 2022-11-02 18:19 UTC (permalink / raw)
  To: Elliott, Robert (Servers),
	Paolo Bonzini, Borislav Petkov, Maxim Levitsky
  Cc: linux-kernel, kvm, Pawan Gupta, Ingo Molnar, Josh Poimboeuf,
	Namhyung Kim, Tony Luck, Arnaldo Carvalho de Melo,
	Thomas Gleixner, Alexander Shishkin, Tim Chen, David S. Miller,
	Dave Hansen, Chang S. Bae, Jane Malalane, Kees Cook, Kan Liang,
	Peter Zijlstra, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Herbert Xu, Jiri Olsa, Mark Rutland, linux-perf-users,
	open list:CRYPTO API

On November 2, 2022 9:23:00 AM PDT, "H. Peter Anvin" <hpa@zytor.com> wrote:
>On November 2, 2022 7:27:52 AM PDT, "Elliott, Robert (Servers)" <elliott@hpe.com> wrote:
>>
>>> From: Paolo Bonzini <pbonzini@redhat.com>
>>...
>>> (2) in particular holds even on bare metal.  The kernel bug here is that
>>> X86_FEATURE_AVX only tells you if the instructions are _present_, not if
>>> they are _usable_.   Indeed, the XCR0 check is present for all other
>>> files in arch/x86/crypto, either instead or in addition to
>>> boot_cpu_has(X86_FEATURE_AVX).
>>> 
>>> Maxim had sent a patch about a year ago to do it in aesni-intel-glue.c
>>> but Dave told him to fix the dependencies instead
>>> (https://lore.kernel.org/all/20211103124614.499580-1-
>>> mlevitsk@redhat.com/).
>>>   What do you think of applying that patch instead?
>>
>>Most of the x86 crypto modules using X86_FEATURE_AVX do check
>>	cpu_has_xfeatures(XFEATURE_MASK_YMM, ...
>>
>>so it's probably prudent to add it to the rest (or remove it everywhere
>>if it is not needed).
>>
>>1. Currently checking XSAVE YMM:
>>  aria_aesni_avx_glue
>>  blake2s-glue
>>  camellia_aesni_avx2_glue	camellia_aesni_avx_glue
>>  cast5_avx_glue		cast6_avx_glue
>>  chacha_glue
>>  poly1305_glue
>>  serpent_avx2_glue		serpent_avx_glue
>>  sha1_ssse3_glue		sha256_ssse3_glue	sha512_ssse3_glue
>>  sm3_avx_glue
>>  sm4_aesni_avx2_glue	sm4_aesni_avx_glue
>>  twofish_avx_glue
>>
>>Currently not checking XSAVE YMM:
>>  aesni-intel_glue
>>  curve25519-x86_64
>>  nhpoly1305-avx2-glue
>>  polyval-clmulni_glue
>>
>>2. Similarly, modules using X86_FEATURE_AVX512F, X86_FEATURE_AVXX512VL
>>and/or X86_FEATURE_AVX512BW probably need to check XFEATURE_MASK_AVX512:
>>
>>Currently checking XSAVE AVX512:
>>  blake2s-glue
>>  poly1305_glue
>>
>>Currently not checking XSAVE AVX512:
>>  chacha_glue
>>
>>3. Similarly, modules using X86_FEATURE_XMM2 probably need to
>>check XFEATURE_MASK_SSE:
>>
>>Currently checking XSAVE SSE:
>>  aegis128-aesni-glue 
>>
>>Current not checking XSAVE SSE:
>>  nhpoly1305-sse2_glue
>>  serpent_sse2_glue
>>
>>
>>
>
>We have a dependency system for CPUID features. If you are going to do this (as opposed to "fixing" this in Qemu or just saying "don't do that, it isn't a valid hardware configuration."
One more thing: for obvious reasons, this doesn't fix user space if user space calls CPUID directly as opposed to reading /proc/cpuinfo or looking in sysfs. Unfortunately this is the rule rather than the exception, although for some features like AVX user space is also supposed to check XCR0, in which case it will work properly anyway.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* RE: [PATCH v2 1/5] perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap
  2022-11-02 18:19                   ` H. Peter Anvin
@ 2022-11-02 19:14                     ` Elliott, Robert (Servers)
  0 siblings, 0 replies; 31+ messages in thread
From: Elliott, Robert (Servers) @ 2022-11-02 19:14 UTC (permalink / raw)
  To: H. Peter Anvin, Paolo Bonzini, Borislav Petkov, Maxim Levitsky
  Cc: linux-kernel, kvm, Pawan Gupta, Ingo Molnar, Josh Poimboeuf,
	Namhyung Kim, Tony Luck, Arnaldo Carvalho de Melo,
	Thomas Gleixner, Alexander Shishkin, Tim Chen, David S. Miller,
	Dave Hansen, Chang S. Bae, Jane Malalane, Kees Cook, Kan Liang,
	Peter Zijlstra, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Herbert Xu, Jiri Olsa, Mark Rutland, linux-perf-users,
	open list:CRYPTO API


> >We have a dependency system for CPUID features. If you are going to do
> this (as opposed to "fixing" this in Qemu or just saying "don't do that,
> it isn't a valid hardware configuration."
> One more thing: for obvious reasons, this doesn't fix user space if user
> space calls CPUID directly as opposed to reading /proc/cpuinfo or looking
> in sysfs. Unfortunately this is the rule rather than the exception,
> although for some features like AVX user space is also supposed to check
> XCR0, in which case it will work properly anyway.

The x86 crypto modules use boot_cpu_has() to check features before
using them.

If that (or some other function that we change them to use) returned false 
if the necessary XSAVE bits were not set, then they could drop the
cpu_has_xfeatures() calls.

arch/x86/kernel/fpu/xstate.c, which provides cpu_has_xfeatures(),
and also has an xsave_cpu_features table listing the features needed
be each xfeature. Perhaps that should provide a cpu_feature_usable()
function that calls boot_cpu_has() and confirms the associated xfeatures
are present. That way the logic would be in one place rather than
replicated in 20+ crypto modules.



^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH v2 1/5] perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap
  2022-11-02 16:23                 ` H. Peter Anvin
  2022-11-02 18:19                   ` H. Peter Anvin
@ 2022-11-03 13:26                   ` Paolo Bonzini
  1 sibling, 0 replies; 31+ messages in thread
From: Paolo Bonzini @ 2022-11-03 13:26 UTC (permalink / raw)
  To: H. Peter Anvin, Elliott, Robert (Servers),
	Borislav Petkov, Maxim Levitsky
  Cc: linux-kernel, kvm, Pawan Gupta, Ingo Molnar, Josh Poimboeuf,
	Namhyung Kim, Tony Luck, Arnaldo Carvalho de Melo,
	Thomas Gleixner, Alexander Shishkin, Tim Chen, David S. Miller,
	Dave Hansen, Chang S. Bae, Jane Malalane, Kees Cook, Kan Liang,
	Peter Zijlstra, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Herbert Xu, Jiri Olsa, Mark Rutland, linux-perf-users,
	open list:CRYPTO API

On 11/2/22 17:23, H. Peter Anvin wrote:
> We have a dependency system for CPUID features. If you are going to
> do this (as opposed to "fixing" this in Qemu or just saying "don't do
> that, it isn't a valid hardware configuration."

I didn't check Robert's full list, but at least in the case of 
aesni-intel_glue this is not about AVX2-depends-on-AVX or 
AVX-depends-on-XSAVE (and it is not about QEMU at all).  It's just that 
checking AVX or AVX2 only tells you about presence and is not enough to 
say whether the instructions are _usable_.  Likewise for AVX512.

What would the dependency be?

Paolo

> 
> 
> 1. Currently checking XSAVE YMM:
>  aria_aesni_avx_glue
>  blake2s-glue
>  camellia_aesni_avx2_glue	camellia_aesni_avx_glue
>  cast5_avx_glue		cast6_avx_glue
>  chacha_glue
>  poly1305_glue
>  serpent_avx2_glue		serpent_avx_glue
>  sha1_ssse3_glue		sha256_ssse3_glue	sha512_ssse3_glue
>  sm3_avx_glue
>  sm4_aesni_avx2_glue	sm4_aesni_avx_glue
>  twofish_avx_glue
> 
> Currently not checking XSAVE YMM:
>  aesni-intel_glue
>  curve25519-x86_64
>  nhpoly1305-avx2-glue
>  polyval-clmulni_glue
> 
> 2. Similarly, modules using X86_FEATURE_AVX512F, X86_FEATURE_AVXX512VL
> and/or X86_FEATURE_AVX512BW probably need to check XFEATURE_MASK_AVX512:
> 
> Currently checking XSAVE AVX512:
>  blake2s-glue
>  poly1305_glue
> 
> Currently not checking XSAVE AVX512:
>  chacha_glue
> 
> 3. Similarly, modules using X86_FEATURE_XMM2 probably need to
> check XFEATURE_MASK_SSE:
> 
> Currently checking XSAVE SSE:
>  aegis128-aesni-glue 
> 
> Current not checking XSAVE SSE:
>  nhpoly1305-sse2_glue
>  serpent_sse2_glue
> 


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH v2 1/5] perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap
  2022-11-02 14:27               ` Elliott, Robert (Servers)
  2022-11-02 16:23                 ` H. Peter Anvin
@ 2022-11-03 13:30                 ` Paolo Bonzini
  1 sibling, 0 replies; 31+ messages in thread
From: Paolo Bonzini @ 2022-11-03 13:30 UTC (permalink / raw)
  To: Elliott, Robert (Servers), Borislav Petkov, Maxim Levitsky
  Cc: linux-kernel, kvm, Pawan Gupta, Ingo Molnar, Josh Poimboeuf,
	Namhyung Kim, Tony Luck, H. Peter Anvin,
	Arnaldo Carvalho de Melo, Thomas Gleixner, Alexander Shishkin,
	Tim Chen, David S. Miller, Dave Hansen, Chang S. Bae,
	Jane Malalane, Kees Cook, Kan Liang, Peter Zijlstra,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Herbert Xu, Jiri Olsa, Mark Rutland, linux-perf-users,
	open list:CRYPTO API

On 11/2/22 15:27, Elliott, Robert (Servers) wrote:
> 
> 3. Similarly, modules using X86_FEATURE_XMM2 probably need to
> check XFEATURE_MASK_SSE:
> 
> Currently checking XSAVE SSE:
>    aegis128-aesni-glue
> 
> Current not checking XSAVE SSE:
>    nhpoly1305-sse2_glue
>    serpent_sse2_glue

These should check boot_cpu_has(X86_FEATURE_FXSR).  Checking 
XFEATURE_MASK_SSE will fail on systems without XSAVE, because 
fpu_kernel_cfg.max_features is zero there (see fpu__init_system_xstate() 
in arch/x86/kernel/fpu/xstate.c).

It happens to work for aegis128-aesni-glue because AES instructions only 
exist on new-enough parts, but it should probably be changed as well.

Paolo


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH v2 2/5] x86/cpuid: refactor setup_clear_cpu_cap()/clear_cpu_cap()
  2022-10-21 16:19   ` Borislav Petkov
@ 2022-11-07 19:10     ` Borislav Petkov
  2022-11-07 21:57       ` Borislav Petkov
  0 siblings, 1 reply; 31+ messages in thread
From: Borislav Petkov @ 2022-11-07 19:10 UTC (permalink / raw)
  To: Maxim Levitsky
  Cc: linux-kernel, kvm, Pawan Gupta, Ingo Molnar, Josh Poimboeuf,
	Namhyung Kim, Tony Luck, Paolo Bonzini, H. Peter Anvin,
	Arnaldo Carvalho de Melo, Thomas Gleixner, Alexander Shishkin,
	Tim Chen, David S. Miller, Dave Hansen, Chang S. Bae,
	Jane Malalane, Kees Cook, Kan Liang, Peter Zijlstra,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Herbert Xu, Jiri Olsa, Mark Rutland, linux-perf-users,
	open list:CRYPTO API

On Fri, Oct 21, 2022 at 06:19:29PM +0200, Borislav Petkov wrote:
> On Mon, Jul 18, 2022 at 05:11:20PM +0300, Maxim Levitsky wrote:
> > Currently setup_clear_cpu_cap passes NULL 'struct cpuinfo_x86*'
> > to clear_cpu_cap to indicate that capability should be cleared from boot_cpu_data.
> > 
> > Later that is used in clear_feature to do recursive call to
> > clear_cpu_cap together with clearing the feature bit from 'cpu_caps_cleared'
> > 
> > Remove that code and just call the do_clear_cpu_cap on boot_cpu_data directly
> > from the setup_clear_cpu_cap.
> > 
> > The only functional change this introduces is that now calling clear_cpu_cap
> > explicitly on boot_cpu_data also sets the bits in cpu_caps_cleared,
> > which is the only thing that makes sense anyway.
> > 
> > All callers of both functions were checked for this and fixed.
> 
> Change looks ok. What I can't grok is this sentence: what was checked
> and fixed where?

Ok, I think I know what you mean. That:

git grep -E "clear_cpu_cap.*boot"
arch/x86/events/intel/lbr.c:1599:       clear_cpu_cap(&boot_cpu_data, X86_FEATURE_ARCH_LBR);
arch/x86/kernel/alternative.c:746:              clear_cpu_cap(&boot_cpu_data, X86_FEATURE_UP);

Right, so here's the difference:

When you call setup_clear_cpu_cap(), it basically means, to disable the
cap on *every* CPU. This is done with cpu_caps_cleared which gets ANDed
in in apply_forced_caps().

clear_cpu_cap() clears the bit *only* in the first parameter supplied.

Now, that first parameter can be boot_cpu_data too but then, strictly
speaking, clear_cpu_cap() would really do what you want it to do - to
clear it only in its first param.

If you really want to enforce that bit cleared everywhere, you need to
use the setup_* variant.

So this patch is actually incorrect but I admit, the CPU caps handling
are kinda subtle and probably need cleaning.

Lemme document it so that it is at least clear. Who knows, we might end
up improving it in the process.

:-)

Thx.

-- 
Regards/Gruss,
    Boris.

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

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH v2 2/5] x86/cpuid: refactor setup_clear_cpu_cap()/clear_cpu_cap()
  2022-11-07 19:10     ` Borislav Petkov
@ 2022-11-07 21:57       ` Borislav Petkov
  0 siblings, 0 replies; 31+ messages in thread
From: Borislav Petkov @ 2022-11-07 21:57 UTC (permalink / raw)
  To: Maxim Levitsky
  Cc: linux-kernel, kvm, Pawan Gupta, Ingo Molnar, Josh Poimboeuf,
	Namhyung Kim, Tony Luck, Paolo Bonzini, H. Peter Anvin,
	Arnaldo Carvalho de Melo, Thomas Gleixner, Alexander Shishkin,
	Tim Chen, David S. Miller, Dave Hansen, Chang S. Bae,
	Jane Malalane, Kees Cook, Kan Liang, Peter Zijlstra,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Herbert Xu, Jiri Olsa, Mark Rutland, linux-perf-users,
	open list:CRYPTO API

On Mon, Nov 07, 2022 at 08:10:42PM +0100, Borislav Petkov wrote:
> Lemme document it so that it is at least clear. Who knows, we might end
> up improving it in the process.

IOW, something like this. It's a start at least...

https://lore.kernel.org/r/20221107211505.8572-1-bp@alien8.de

-- 
Regards/Gruss,
    Boris.

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

^ permalink raw reply	[flat|nested] 31+ messages in thread

end of thread, other threads:[~2022-11-07 21:58 UTC | newest]

Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-18 14:11 [PATCH v2 0/5] x86: cpuid: improve support for broken CPUID configurations Maxim Levitsky
2022-07-18 14:11 ` [PATCH v2 1/5] perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap Maxim Levitsky
2022-09-19 14:31   ` Borislav Petkov
2022-09-20  8:20     ` Maxim Levitsky
2022-09-26 13:12       ` Borislav Petkov
2022-09-28 10:49         ` Maxim Levitsky
2022-10-20  8:59           ` Borislav Petkov
2022-10-20  9:05             ` Herbert Xu
2022-10-20 10:21               ` Maxim Levitsky
2022-10-20 11:13                 ` Borislav Petkov
2022-10-22 21:08             ` H. Peter Anvin
2022-11-02 13:40             ` Paolo Bonzini
2022-11-02 14:27               ` Elliott, Robert (Servers)
2022-11-02 16:23                 ` H. Peter Anvin
2022-11-02 18:19                   ` H. Peter Anvin
2022-11-02 19:14                     ` Elliott, Robert (Servers)
2022-11-03 13:26                   ` Paolo Bonzini
2022-11-03 13:30                 ` Paolo Bonzini
2022-10-20 15:17   ` [tip: x86/urgent] perf/x86/intel/lbr: Use setup_clear_cpu_cap() instead of clear_cpu_cap() tip-bot2 for Maxim Levitsky
2022-07-18 14:11 ` [PATCH v2 2/5] x86/cpuid: refactor setup_clear_cpu_cap()/clear_cpu_cap() Maxim Levitsky
2022-10-21 16:19   ` Borislav Petkov
2022-11-07 19:10     ` Borislav Petkov
2022-11-07 21:57       ` Borislav Petkov
2022-07-18 14:11 ` [PATCH v2 3/5] x86/cpuid: move filter_cpuid_features to cpuid-deps.c Maxim Levitsky
2022-07-18 14:11 ` [PATCH v2 4/5] x86/cpuid: remove 'warn' parameter from filter_cpuid_features Maxim Levitsky
2022-07-18 14:11 ` [PATCH v2 5/5] x86/cpuid: check for dependencies violations in CPUID and attempt to fix them Maxim Levitsky
2022-07-28  7:30 ` [PATCH v2 0/5] x86: cpuid: improve support for broken CPUID configurations Maxim Levitsky
2022-08-01 16:05   ` Maxim Levitsky
2022-08-01 16:31     ` Dave Hansen
2022-08-01 16:41       ` Maxim Levitsky
2022-09-19 13:43     ` Maxim Levitsky

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).