CPU microcode reported wrong in /proc/cpuinfo

[Brian Inglis]

On 2020-07-16 08:56, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
>> Managed to get this tested and applied thanks to your help and it has landed in
>> new Cygwin 3.1.6 so please post your results and any further comments when you
>> have a chance to upgrade and test.
> 
> I checked it out in the new Cygwin 3.1.6, and it shows microcode version
> correctly now, but assuming Windows was booted up from the initial power-on,
> i.e. after BIOS POST.
> 
> There's another problem, though...  After wakeup (from sleep), Windows
> reports microcode versions in the registry weirdly.
> 
> Only the CPU0 (which in my case core 0) is reported with the same info that
> was reported for all cores after the initial boot-up, all other cores are
> reported with some old microcode version (I presume that's the microcode that
> Windows has on its own in one of its CPU driver DLLs).
> 
> So for core 0 it is as it was (and for all of them after the boot-up):
> 
> C:\Windows\system32>regtool list -v /proc/registry/HKEY_LOCAL_MACHINE/HARDWARE/DESCRIPTION/System/CentralProcessor/0/
> Component Information (REG_BINARY) = 00 00 00 00 00 00 00 00
> Identifier (REG_SZ) = "Intel64 Family 6 Model 23 Stepping 10"
> Configuration Data (REG_FULL_RESOURCE_DESCRIPTOR) = ?
> ProcessorNameString (REG_SZ) = "Intel(R) Xeon(R) CPU           X5470  @ 3.33GHz"
> VendorIdentifier (REG_SZ) = "GenuineIntel"
> FeatureSet (REG_DWORD) = 0x215b3ffe (559628286)
> ~MHz (REG_DWORD) = 0x00000d04 (3332)
> Update Signature (REG_BINARY) = 00 00 00 00 0e 0a 00 00
> Update Status (REG_DWORD) = 0x00000007 (7)
> Previous Update Signature (REG_BINARY) = 00 00 00 00 0e 0a 00 00
> Platform ID (REG_DWORD) = 0x00000040 (64)
> 
> For other cores (1-3), it's this (after wake-up; but after the boot-up it
> was the same as the above for core 0):
> 
> C:\Windows\system32>regtool list -v /proc/registry/HKEY_LOCAL_MACHINE/HARDWARE/DESCRIPTION/System/CentralProcessor/1/
> Component Information (REG_BINARY) = 00 00 00 00 00 00 00 00
> Identifier (REG_SZ) = "Intel64 Family 6 Model 23 Stepping 10"
> Configuration Data (REG_FULL_RESOURCE_DESCRIPTOR) = ?
> ProcessorNameString (REG_SZ) = "Intel(R) Xeon(R) CPU           X5470  @ 3.33GHz"
> VendorIdentifier (REG_SZ) = "GenuineIntel"
> FeatureSet (REG_DWORD) = 0x215b3ffe (559628286)
> ~MHz (REG_DWORD) = 0x00000d04 (3332)
> Update Signature (REG_BINARY) = 00 00 00 00 0b 0a 00 00
> Update Status (REG_DWORD) = 0x00000000 (0)
> Previous Update Signature (REG_BINARY) = 00 00 00 00 00 00 00 00
> Platform ID (REG_DWORD) = 0x00000040 (64)
> 
> Note that there's no "Previous Update Signature" in the latter case, and 
> "Update Status" is 0 (instead of 7, for core 0, and what it also was for
> these same cores 1-3 after the boot-up).  I'm being repetitive to underscore
> the noted differences.
> 
> So Cygwin reports these same values in its /proc/cpuinfo output (core0: 
> 0xA0E, cores1-3: 0xA0B)... Meanwhile, Intel CPU ID utility keeps saying the 
> CPU microcode version is still 0xA0E (they don't show "per-core" values, if 
> that was the thing at all), and so does HWiNFO64 (again for the CPU as a
> whole).
> 
> I'm not exactly sure how to read Window's registry values with cores on the 
> same CPU having different microcode versions (is that even possible?)

Should not be unless the status differs or the hybrid bit is set saying CPUs are
different.
Depending on the CPU, ucode updates may be loaded on the boot core only, or on
all cores:
https://software.intel.com/security-software-guidance/insights/microcode-update-guidance
It may be possible that Windows executes a CPUID instruction, and then reads MSR
8BH IA32_BIOS_SIGN_ID to get the current value, without first preloading the MSR
with zero, and rather than interpreting the zero result as unchanged, just
reports that value.
So I think you probably encountered another Windows sleep bug, but VMs should
not care if different values are returned after a sleep, if VMs are run at
startup before any sleeps, although obviously starting a VM after a sleep could
cause issues, especially on current Intel CPUs where mitigations required could
be ucode version dependent if there are not feature or behaviour dependencies to
check.
If you are on Windows 10 you could report the issue to MS through the Feedback
Hub app.

> I tried to dig into what "Update Status" means, but I couldn't find any
> useful information, unfortunately.
> 
> I suspect that "0" means a successful update, but that would also mean that 
> Windows updated ucode in cores 1-3 from nothing to 0xA0B -- and I checked
> that that's the latest microcode that is shipped with this version of
> Windows, as a Windows Update, for this CPU.  I found one post that said that
> "Update Status" 6 would mean no matching update found, but there is no 6 in
> my case.
Correct AFAIK:
0 - ucode loading supported by CPU - update available and successfully applied -
loaded ucode (Update...) != BIOS boot ucode (Previous Update...)
1 - ucode loading not supported by CPU - not loadable and not available - no
Update... or Previous... data or loaded ucode (Update...) == BIOS boot ucode
(Previous Update...) - may mean ucode changes are supported only in BIOS at
power on thru BIOS updates
2 - ucode loading supported by CPU - no ucode update available - loaded ucode
(Update...) == BIOS boot ucode (Previous Update...)
3-7 loading phase (early/late BIOS or OS) or error status?

> An interesting fact is that when I run Linux in VMWare on Windows woken up 
> from sleep, allocating two CPUs for the VM, I can get a mix of one 0xA0E and
> one 0xA0B ucode reported in "/proc/cpuinfo" for the cores, or it can be two
> 0xA0Bs. But it looks like Linux knows exactly it is run virtualized on
> VMWare, and so may not be reporting from the actual values from the MSRs for
> that.  I also noticed that it does not attempt to load any microcode in this
> case.  When I use VirtualBox for the same, I get a completely different
> microcode version output (but so far consistent and same for both cores),
> 0x60B (which I don't think is a valid value at all, TBH).  Yet the same, it
> does not looks like it attempts to load any on its own because it knows it is
> run virtualized (yet it does not state exactly the host OS VM software unlike
> it does with VMWare).
> 
> So, apologies for the long post.  I just tried to be thorough ;-)

VM guests should not be able to directly read MSRs, unless they are running with
kernel privileges, but VM hosts may provide cached values or execute the MSR and
return the result.
VM hosts may report various values to ensure that guests do not try to use
features that the virtualization can not support and maintain stable operation
within bounds: no dependencies on timing of instructions, between instructions,
operations of interruptible instructions, or instruction sequences, using only
architected interfaces which make timing data available.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]