x86 CPUID mutable return values

x86 CPUID mutable return values

[Christian Ludloff]

Back in May I wrote...

> https://lore.kernel.org/lkml/CAKSQd8XM6p7TTVih9fg9fmUAkzNchPCT7B-6qzVuja=3hg_u+A@mail.gmail.com/
>
> When deciding what the code shall do for mutable CPUID bits,
> you really want to have an exhaustive list of events that trigger
> changes – think Intel SDM vol1 21.1.5 as a starting point; then
> made exhaustive for all events, for Intel and the other vendors.

I annotated https://www.sandpile.org/x86/cpuid.htm – you can
search for "mutable", to get a little over 70 hits.

I can mark AES and PCLMUL as well... pending confirmation:

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?

Q for AMD: is MSR DE_CFG 0xC001_1029 bit 16 expected to
affect just CPUID 1.ECX.25/1 and 7.0.ECX.10/9?

If there are more mutable bits or fields, then please speak up.

Ahmed – is there a proper way to reflect "mutable" in the db?

> (Besides on/off bits spread all over the place, microcode loads
> at runtime come to mind as... uhm... interesting...)

Presumably ucode loads should trigger a full CPUID re-read?

Last but not least, there was the case of the Rise mP6 config
leaves, i.e. CPUID, abused for applying config settings. Look
at https://www.sandpile.org/x86/cpuid.htm#leaf_6363_4523h
for basic information – it's unclear what effect these had... for
all we know, it could have been CPUID... affecting... itself...?

Ahmed – I don't know how you want to reflect that in the db?

--
C.

Re: x86 CPUID mutable return values

[Dave Hansen]

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?

I poked around on a few pieces of hardware I have within reach and all
of them have the MSR FEATURE_CONFIG lock bit set and the disable bit clear.

# rdmsr -a 0x13C
1
1
1
1
...

In practice, I suspect the AESNI CPUID bits are immutable.

FEATURE_CONFIG's definitions also looks model specific in the spots I
see it in the SDM. They're also not identical, interestingly enough.

Honestly, FEATURE_CONFIG looks more like something that should have been
in the BIOS writers' guide rather than the SDM.

Re: x86 CPUID mutable return values

[Christian Ludloff]

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.

> I poked around on a few pieces of hardware I have within reach and all
> of them have the MSR FEATURE_CONFIG lock bit set and the disable bit clear.
>
> # rdmsr -a 0x13C
> 1
> 1
> 1
> 1
> ...
>
> In practice, I suspect the AESNI CPUID bits are immutable.

If the LOCK bit is set. Which is recommended.

But apparently not always done. No surprises.

> FEATURE_CONFIG's definitions also looks model specific in the spots I see it in the SDM. They're also not identical, interestingly enough.

While the verbiage across documents mutated
a bit over time, the functionality of DISABLE as
well as LOCK seems to have been immutable
ever since WSM and GLM introduced them.

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.

> 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?

--
C.

Re: x86 CPUID mutable return values

[Dave Hansen]

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.

Re: x86 CPUID mutable return values

[Christian Ludloff]

On Tue, Sep 22, 2026 at 5:24 PM Dave Hansen <dave.hansen@intel.com> wrote:
> I'm all for documenting this stuff. I wish it was more open.

Alastair is working on it.

https://github.com/intel/SDM/issues/16

> 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.

Most of the mutable values tend to remain stable.

HLE and RTM were needlessly complex outliers.

> > 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?

TGL would be interesting – KL did arrive back then.

NVL would be interesting – for the latest P+E – but
we probably have to settle for PTL for now.

> > 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.

AES DISABLE+LOCK were originally added due to
import rules in some countries.

> 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.

If LOCK=0 leads to someone setting DISABLE=1,
then things will get slow, or do who knows what in
software. But then... armed with WRMSR to begin
with, someone can do a lot more damage anyway.

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

Yay. We gave it thought, and got us a record of it.

--
C.