Re: [PATCH v11 3/4] x86/cpu: Do a sanity check on required feature bits

["H. Peter Anvin" <hpa@zytor.com>]

On 2026-03-23 09:31, Borislav Petkov wrote:
> 
> AFAICT, if *any* of those features are not set, the machine will crash'n'burn
> anyway.
> 
> So the required features will be "enforced" pretty early :-)
> 
> Otherwise they're not really required.
> 
> And besides, what's
> 
> arch/x86/kernel/verify_cpu.S
> 
> for if not for that?
> 

That is not necessarily true at all. As such, this may be a really cheap way
to get a message out in case we get that far without problems.

For one thing, this runs -- at least on the BSP -- before either alternatives
patching or running user space, so there is plenty of features that may not
have been used yet.

For another thing, there are some features -- such as PAE to mention one --
that are present in some CPUs but disabled in CPUID because for some reason or
another the manufacturer found during testing that it doesn't always work
right. However, it is likely that a PAE kernel will successfully boot, and it
might even work on any one particular CPU. This is *exactly* what
TAINT_CPU_OUT_OF_SPEC is supposed to represent.

Finally, as Maciej reported, the user might have tried to explicitly override
a required feature.

verify_cpu.S serves a different purpose: is to enable features that are
required to even set up the kernel execution environment and that may be
switched off through various mechanisms.

verify_cpu.S is unfortunately not able to issue messages (not to mention that
it is written in assembly, *AND* it doesn't have access to all the rules and
exceptions that are coded into arch/x86/kernel/cpu/*.) There *is* a messaging
function in the BIOS stub, but there is no equivalent in for code that bypass
this stage (which is of course standard these days.) verify_cpu.S just returns
a single bit, and that only represents checking for a few very basic features.