From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
After cpu_caps_cleared[] is initialized with DISABLED_MASK_INIT,
features present in disabled bitmasks are cleared from x86_capability[].
However features that depend on them and are not part of any disabled
mask are not cleared by anything. They can trigger the warning in
check_cpufeature_deps(), as before both features would show up as
enabled even though they weren't. The uncleared features can also still
falsely show up in /proc/cpuinfo.
Running setup_clear_cpu_cap() on such cases inside
check_cpufeature_deps() should guarantee that the cleanup of the
leftover bits has to run only once. Afterwards apply_forced_caps()
clears the leftover bits from x86_capability[] and the warning inside
check_cpufeature_deps() doesn't trigger anymore.
Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
---
Changelog v11:
- Add this patch to the series.
arch/x86/kernel/cpu/cpuid-deps.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c
index 5002f496d095..b0f5d3fe6655 100644
--- a/arch/x86/kernel/cpu/cpuid-deps.c
+++ b/arch/x86/kernel/cpu/cpuid-deps.c
@@ -163,6 +163,16 @@ void check_cpufeature_deps(struct cpuinfo_x86 *c)
for (d = cpuid_deps; d->feature; d++) {
if (cpu_has(c, d->feature) && !cpu_has(c, d->depends)) {
+ /*
+ * If the dependency was cleared through the disabled
+ * bitmasks while the feature wasn't it also needs to be
+ * cleared.
+ */
+ if (!DISABLED_MASK_BIT_SET(d->feature) && DISABLED_MASK_BIT_SET(d->depends)) {
+ setup_clear_cpu_cap(d->feature);
+ continue;
+ }
+
/*
* Only warn about the first unmet dependency on the
* first CPU where it is encountered to avoid spamming
--
2.53.0On Fri, Mar 20, 2026 at 12:50:29PM +0000, Maciej Wieczor-Retman wrote:
> From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
>
> After cpu_caps_cleared[] is initialized with DISABLED_MASK_INIT,
> features present in disabled bitmasks are cleared from x86_capability[].
> However features that depend on them and are not part of any disabled
> mask are not cleared by anything. They can trigger the warning in
> check_cpufeature_deps(), as before both features would show up as
> enabled even though they weren't. The uncleared features can also still
> falsely show up in /proc/cpuinfo.
Well, why aren't we clearing those apply_forced_caps() too instead of clearing
them at check time?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On 2026-03-23 at 17:35:57 +0100, Borislav Petkov wrote: >On Fri, Mar 20, 2026 at 12:50:29PM +0000, Maciej Wieczor-Retman wrote: >> From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com> >> >> After cpu_caps_cleared[] is initialized with DISABLED_MASK_INIT, >> features present in disabled bitmasks are cleared from x86_capability[]. >> However features that depend on them and are not part of any disabled >> mask are not cleared by anything. They can trigger the warning in >> check_cpufeature_deps(), as before both features would show up as >> enabled even though they weren't. The uncleared features can also still >> falsely show up in /proc/cpuinfo. > >Well, why aren't we clearing those apply_forced_caps() too instead of clearing >them at check time? At the moment only the SGX + SGX_LC pair can cause this problem (case of SGX is not compiled and it has X86_DISABLED_FEATURE_SGX while SGX_LC depends on SGX but doesn't have X86_DISABLED_FEATURE_SGX_LC defined therefore it is not automatically cleared). Clearing the compile time disabled bits is fairly low effort since it's just initializing the cpu_caps_cleared[]. To validate the whole cpuid_deps[] array and add relevant bits to cpu_caps_cleared[] would probably require adding another loop that would check all of the entries. Since now only SGX has this problem I didn't think it warranted adding more than this check in check_cpufeature_deps(). > >-- >Regards/Gruss, > Boris. > >https://people.kernel.org/tglx/notes-about-netiquette -- Kind regards Maciej Wieczór-Retman
On Mon, Mar 23, 2026 at 05:23:19PM +0000, Maciej Wieczor-Retman wrote:
> Clearing the compile time disabled bits is fairly low effort since it's just
> initializing the cpu_caps_cleared[].
and cpu_caps_cleared[] is consulted in apply_forced_caps().
> To validate the whole cpuid_deps[] array and add relevant bits to
> cpu_caps_cleared[] would probably require adding another loop that would
> check all of the entries. Since now only SGX has this problem I didn't think
> it warranted adding more than this check in check_cpufeature_deps().
So we're going to do half-baked solution again and it'll come to bite us in
the ass later?
How about we hammer it out properly once and for all?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On 2026-03-23 10:59, Borislav Petkov wrote: > On Mon, Mar 23, 2026 at 05:23:19PM +0000, Maciej Wieczor-Retman wrote: >> Clearing the compile time disabled bits is fairly low effort since it's just >> initializing the cpu_caps_cleared[]. > > and cpu_caps_cleared[] is consulted in apply_forced_caps(). > >> To validate the whole cpuid_deps[] array and add relevant bits to >> cpu_caps_cleared[] would probably require adding another loop that would >> check all of the entries. Since now only SGX has this problem I didn't think >> it warranted adding more than this check in check_cpufeature_deps(). > > So we're going to do half-baked solution again and it'll come to bite us in > the ass later? > > How about we hammer it out properly once and for all? > One could argue that the Right Thing[TM] to do would be to encode the dependencies in a file that can be processed at compile time, and have those features explicitly added to the enabled and disabled masks, basically augmenting Kconfig.cpufeatures. The sanest way to do that would probably be to move cpuid_deps[] from cpuid-deps.c into a standalone file which can be processed by cpufeaturesmask.awk or equivalent. I do have to say that using awk for these things, especially being restricted to POSIX awk, is really awful as it really is pushing the limits of that tool. String processing in C is most definitely no fun either -- the single biggest shortcoming of what is otherwise one of my favorite languages -- but it *would* also be possible to refactor cpuid-deps.c so that it can be compiled in user space and linked with a C tool that would replace cpufeaturesmask.awk, mkcapflags.sh, and boot/mkcpustr.c. This seemed to me to be a bit excessive in terms of churn and complexity, but perhaps this is what you are looking for? -hpa
On Mon, Mar 23, 2026 at 11:57:45AM -0700, H. Peter Anvin wrote:
> I do have to say that using awk for these things, especially being restricted
> to POSIX awk, is really awful as it really is pushing the limits of that tool.
> String processing in C is most definitely no fun either -- the single biggest
> shortcoming of what is otherwise one of my favorite languages -- but it
> *would* also be possible to refactor cpuid-deps.c so that it can be compiled
> in user space and linked with a C tool that would replace cpufeaturesmask.awk,
> mkcapflags.sh, and boot/mkcpustr.c.
>
> This seemed to me to be a bit excessive in terms of churn and complexity, but
> perhaps this is what you are looking for?
I was actually suggesting we handle the dependent features in
apply_forced_caps() and keep that all in one place.
As to the whole glue handling deps, feature flags, names, yadda yadda, yap,
I agree, it ain't easy and I need to grep each time where the generated files
are and go stare at them.
So I really like the idea of replacing it all with a C tool which you can
massage in luserspace and replace all that other gunk and we won't depend on
the awk flavor or shell script or whatnot but keep everything in a single
C program and a header.
I don't know whether that would work and how ugly it would become - we need to
try it I guess - but the idea ure sounds enticing...
Maybe something for a future todo.
:-)
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On 2026-03-23 at 20:30:33 +0100, Borislav Petkov wrote: >On Mon, Mar 23, 2026 at 11:57:45AM -0700, H. Peter Anvin wrote: >> I do have to say that using awk for these things, especially being restricted >> to POSIX awk, is really awful as it really is pushing the limits of that tool. >> String processing in C is most definitely no fun either -- the single biggest >> shortcoming of what is otherwise one of my favorite languages -- but it >> *would* also be possible to refactor cpuid-deps.c so that it can be compiled >> in user space and linked with a C tool that would replace cpufeaturesmask.awk, >> mkcapflags.sh, and boot/mkcpustr.c. >> >> This seemed to me to be a bit excessive in terms of churn and complexity, but >> perhaps this is what you are looking for? > >I was actually suggesting we handle the dependent features in >apply_forced_caps() and keep that all in one place. > >As to the whole glue handling deps, feature flags, names, yadda yadda, yap, >I agree, it ain't easy and I need to grep each time where the generated files >are and go stare at them. > >So I really like the idea of replacing it all with a C tool which you can >massage in luserspace and replace all that other gunk and we won't depend on >the awk flavor or shell script or whatnot but keep everything in a single >C program and a header. > >I don't know whether that would work and how ugly it would become - we need to >try it I guess - but the idea ure sounds enticing... > >Maybe something for a future todo. > >:-) > >-- >Regards/Gruss, > Boris. > >https://people.kernel.org/tglx/notes-about-netiquette I'll move the cpuid_deps[] checking to apply_forced_caps() for now then. I can try giving the C tool a shot too, we were previously thinking that merging x86_cap_flags[] and x86_bug_flags[] could be a nice cleanup. But using the current scripts that turned out to not have any real benefits, maybe that's worth looking into as well when rewriting the scripts into C? -- Kind regards Maciej Wieczór-Retman
On Mon, 23 Mar 2026, H. Peter Anvin wrote: > > On 2026-03-23 10:59, Borislav Petkov wrote: > > On Mon, Mar 23, 2026 at 05:23:19PM +0000, Maciej Wieczor-Retman wrote: > >> Clearing the compile time disabled bits is fairly low effort since it's just > >> initializing the cpu_caps_cleared[]. > > > > and cpu_caps_cleared[] is consulted in apply_forced_caps(). > > > >> To validate the whole cpuid_deps[] array and add relevant bits to > >> cpu_caps_cleared[] would probably require adding another loop that would > >> check all of the entries. Since now only SGX has this problem I didn't think > >> it warranted adding more than this check in check_cpufeature_deps(). > > > > So we're going to do half-baked solution again and it'll come to bite us in > > the ass later? > > > > How about we hammer it out properly once and for all? > > > > One could argue that the Right Thing[TM] to do would be to encode the > dependencies in a file that can be processed at compile time, and have those > features explicitly added to the enabled and disabled masks, basically > augmenting Kconfig.cpufeatures. > > The sanest way to do that would probably be to move cpuid_deps[] from > cpuid-deps.c into a standalone file which can be processed by > cpufeaturesmask.awk or equivalent. > I'm posting the CPUID patch queue tomorrow. It has all the X86_FEATURE words (synthetic and hardware-backed) modeled and mapped by x86-cpuid-db. These XMLs are definitely the right place to encode the dependencies, as there is already different types of generators in the project. The series cover letter tomorrow will cover a lot of details on this. Thanks! Ahmed
On 2026-03-23 at 18:59:02 +0100, Borislav Petkov wrote: >On Mon, Mar 23, 2026 at 05:23:19PM +0000, Maciej Wieczor-Retman wrote: >> Clearing the compile time disabled bits is fairly low effort since it's just >> initializing the cpu_caps_cleared[]. > >and cpu_caps_cleared[] is consulted in apply_forced_caps(). > >> To validate the whole cpuid_deps[] array and add relevant bits to >> cpu_caps_cleared[] would probably require adding another loop that would >> check all of the entries. Since now only SGX has this problem I didn't think >> it warranted adding more than this check in check_cpufeature_deps(). > >So we're going to do half-baked solution again and it'll come to bite us in >the ass later? > >How about we hammer it out properly once and for all? > >-- >Regards/Gruss, > Boris. > >https://people.kernel.org/tglx/notes-about-netiquette Okay, I'll work on a helper/loop to check the whole array and clear such cases somewhat early so the warning in check_cpufeature_deps() doesn't get triggered. -- Kind regards Maciej Wieczór-Retman
© 2016 - 2026 Red Hat, Inc.