Re: x86 CPUID mutable return values

[Dave Hansen <dave.hansen@intel.com>]

On 9/22/26 01:43, Christian Ludloff wrote:
> On Mon, Sep 21, 2026 at 11:32 PM Dave Hansen <dave.hansen@intel.com> wrote:
>>
>> On 9/21/26 11:36, Christian Ludloff wrote:
>>> Q for Intel: is MSR FEATURE_CONFIG 0x13C bit 1 expected
>>> to affect CPUID 1.ECX.25 and 7.0.ECX.9 and 19.EBX.0/2, or
>>> just just a subset of them? Also, what about PCLMUL?
>>
>> Are you looking to document architecture or implementation here?
> 
> Just the reality of mutable CPUID return values.
> 
> Because it matters. When trying to cache them.

Of course.

I'm all for documenting this stuff. I wish it was more open. But I do
worry a bit that someone will read that, for example, "KL is immutable".
$CUSTOMER starts depending on it. Then, $CPU_VENDOR decides that was a
mistake and fixes it in a future implementation.

> Based on some experiments, I think that VAES
> does follow AES (i.e. is mutable as well), while
> KL and PCLMUL do not (i.e. are immutable) –
> so that's what I am seeking confirmation for.

Are you OK with just checking a recent implementation or do you need a
wider search of older implementations?

>> Honestly, FEATURE_CONFIG looks more like something that should have been in the BIOS writers' guide rather than the SDM.
> 
> I for one appreciate that the SDM attempts to
> provide a list of mutable CPUID return values
> and that it has the FEATURE_CONFIG MSR.
> 
> After all... the most recent public Intel BWG is
> more than 30 years old by now [aka P6 days],
> and https://en.wikipedia.org/wiki/Appendix_H
> was a thing that also happened back then.  :)
> 
> PS: Should Linux boot check/fix that LOCK?
I don't really feel a strong need to do it. I honestly don't know why
the lock bit is even there. I'd randomly _guess_ that Intel's
implementation was not certified for $THINGS and they got nervous and
asked to have a chicken bit exposed for it just so it couldn't
accidentally get used.

But, for Linux, the kernel doesn't currently munging the disable or lock
bits. If someone munges it with wrmsr(1), they get to keep the pieces
just like any old wrmsr(1) user. I'm struggling to think of a scenario
where being able to twiddle either of the bits could be useful to an
attacker.

So I'm not sure it's worth prodding, even if we think it's got a funny
value.