RE: CPU microcode reported wrong in /proc/cpuinfo

RE: CPU microcode reported wrong in /proc/cpuinfo

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

> also have to look for Update Signature

It's Windows 7 here (Windows 10 uses newer registry key names, with the word "Revision" in them, instead).

> Could you please run:

$ head /proc/version
CYGWIN_NT-6.1-7601 version 3.1.4-340.x86_64 (corinna@calimero) (gcc version 7.4.0 20181206 (Fedora Cygwin 7.4.0-1) (GCC) ) 2020-02-19 08:49 UTC

$ regtool list -v "/proc/registry/HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows NT/CurrentVersion/" | fgrep =
CurrentVersion (REG_SZ) = "6.1"
CurrentBuild (REG_SZ) = "7601"
SoftwareType (REG_SZ) = "System"
CurrentType (REG_SZ) = "Multiprocessor Free"
InstallDate (REG_DWORD) = 0x54373393 (1412903827)
RegisteredOrganization (REG_SZ) = ""
RegisteredOwner (REG_SZ) = "ANTON"
SystemRoot (REG_SZ) = "C:\Windows"
InstallationType (REG_SZ) = "Client"
EditionID (REG_SZ) = "HomePremium"
ProductName (REG_SZ) = "Windows 7 Home Premium"
ProductId (REG_SZ) = "00359-OEM-8702121-81656"
DigitalProductId (REG_BINARY) = a4 00 00 00 03 00 00 00
DigitalProductId4 (REG_BINARY) = f8 04 00 00 04 00 00 00
CurrentBuildNumber (REG_SZ) = "7601"
BuildLab (REG_SZ) = "7601.win7sp1_ldr_escrow.200102-1707"
BuildLabEx (REG_SZ) = "7601.24545.amd64fre.win7sp1_ldr_escrow.200102-1707"
BuildGUID (REG_SZ) = "3b42db76-c1db-4ecd-8368-b2e532306b4a"
CSDBuildNumber (REG_SZ) = "1130"
PathName (REG_SZ) = "C:\Windows"
CSDVersion (REG_SZ) = "Service Pack 1"
UBR (REG_DWORD) = 0x00005fe2 (24546)

$ 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)

P.S. I have since updated the microcode to version 0xA0E (from 0xA0B that used to show in my last email).

Re: CPU microcode reported wrong in /proc/cpuinfo

[Brian Inglis]

On 2020-06-10 09:34, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
>> also have to look for Update Signature
> 
> It's Windows 7 here (Windows 10 uses newer registry key names, with the word "Revision" in them, instead).
> 
>> Could you please run:
> 
> $ head /proc/version
> CYGWIN_NT-6.1-7601 version 3.1.4-340.x86_64 (corinna@calimero) (gcc version 7.4.0 20181206 (Fedora Cygwin 7.4.0-1) (GCC) ) 2020-02-19 08:49 UTC
> 
> $ regtool list -v "/proc/registry/HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows NT/CurrentVersion/" | fgrep =
> CurrentVersion (REG_SZ) = "6.1"
> CurrentBuild (REG_SZ) = "7601"
> SoftwareType (REG_SZ) = "System"
> CurrentType (REG_SZ) = "Multiprocessor Free"
> InstallDate (REG_DWORD) = 0x54373393 (1412903827)
> RegisteredOrganization (REG_SZ) = ""
> RegisteredOwner (REG_SZ) = "ANTON"
> SystemRoot (REG_SZ) = "C:\Windows"
> InstallationType (REG_SZ) = "Client"
> EditionID (REG_SZ) = "HomePremium"
> ProductName (REG_SZ) = "Windows 7 Home Premium"
> ProductId (REG_SZ) = "00359-OEM-8702121-81656"
> DigitalProductId (REG_BINARY) = a4 00 00 00 03 00 00 00
> DigitalProductId4 (REG_BINARY) = f8 04 00 00 04 00 00 00
> CurrentBuildNumber (REG_SZ) = "7601"
> BuildLab (REG_SZ) = "7601.win7sp1_ldr_escrow.200102-1707"
> BuildLabEx (REG_SZ) = "7601.24545.amd64fre.win7sp1_ldr_escrow.200102-1707"
> BuildGUID (REG_SZ) = "3b42db76-c1db-4ecd-8368-b2e532306b4a"
> CSDBuildNumber (REG_SZ) = "1130"
> PathName (REG_SZ) = "C:\Windows"
> CSDVersion (REG_SZ) = "Service Pack 1"
> UBR (REG_DWORD) = 0x00005fe2 (24546)
> 
> $ 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)
> 
> P.S. I have since updated the microcode to version 0xA0E (from 0xA0B that used to show in my last email).

Thanks for that info.
I think I may now have an approach that will work across all known microcode
registry values, but having testing problems.

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

RE: CPU microcode reported wrong in /proc/cpuinfo

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

> https://software.intel.com/security-software-guidance/insights/microcode-update-guidance

Thanks, interesting reading.

I think in my case the ucode update is done via the FIT method, though, as the latest microcode (0xA0E) is included in the re-packaged BIOS, and re-flashed into ROM along with it.

RE: CPU microcode reported wrong in /proc/cpuinfo

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

> So I think you probably encountered another Windows sleep bug

Quite possibly...  The microcode version in the registry looks okay after wake-up from hibernate, though (but that subsumes the system POST and clean boot).

> 0 - ucode loading supported by CPU - update available and successfully applied - loaded ucode (Update...) != BIOS boot ucode (Previous Update...)

Hmmm, cores1-3 "updated" after sleep?  I think it must be a bug then, indeed.

> If you are on Windows 10 you could report the issue to MS

Nah, Windows 7 here...  No longer "supported"

RE: CPU microcode reported wrong in /proc/cpuinfo

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

> I'll have to recheck how Linux handles these

JFYI I was in correspondence with the cpuid utility team lately, and they told me that Linux uses vendor-specific MSRs to pull that info out:

> Check out:
> 
>    MSR_IA32_UCODE_REV
>    MSR_AMD64_PATCH_LEVEL
> 
> Both reference MSR 0x8b.

Re: CPU microcode reported wrong in /proc/cpuinfo

[Brian Inglis]

On 2020-06-10 14:23, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
>> I'll have to recheck how Linux handles these
> 
> JFYI I was in correspondence with the cpuid utility team lately, and they told me that Linux uses vendor-specific MSRs to pull that info out:
> 
>> Check out:
>>
>>    MSR_IA32_UCODE_REV
>>    MSR_AMD64_PATCH_LEVEL
>>
>> Both reference MSR 0x8b.

As does MS, as I also tracked down some older MS Windows microcode registry
values used, whose names also appear to be based on the earlier MSR names.
Using MSRs are not an option, as MS Windows appears to provide no documented
access to those register values, and they are only accessible from kernel level
drivers, which are not available for latest MS Windows (i.e. I don't trust
offered drivers that claim to provide MSR access!)

I have applied a patch for this, and rebuilt cygwin, but are having problems
testing with the new dll (as are some others), so need some time to figure out
what are the minimum synced pieces now required to be able to test!

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

Re: CPU microcode reported wrong in /proc/cpuinfo

[Brian Inglis]

On 2020-06-10 15:45, Brian Inglis wrote:
> On 2020-06-10 14:23, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
>>> I'll have to recheck how Linux handles these
>>
>> JFYI I was in correspondence with the cpuid utility team lately, and they told me that Linux uses vendor-specific MSRs to pull that info out:
>>
>>> Check out:
>>>
>>>    MSR_IA32_UCODE_REV
>>>    MSR_AMD64_PATCH_LEVEL
>>>
>>> Both reference MSR 0x8b.
> 
> As does MS, as I also tracked down some older MS Windows microcode registry
> values used, whose names also appear to be based on the earlier MSR names.
> Using MSRs are not an option, as MS Windows appears to provide no documented
> access to those register values, and they are only accessible from kernel level
> drivers, which are not available for latest MS Windows (i.e. I don't trust
> offered drivers that claim to provide MSR access!)
> 
> I have applied a patch for this, and rebuilt cygwin, but are having problems
> testing with the new dll (as are some others), so need some time to figure out
> what are the minimum synced pieces now required to be able to test!

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.

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

RE: CPU microcode reported wrong in /proc/cpuinfo

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

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

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.

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 ;-)

Thanks,
Anton

Re: 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.]

Re: CPU microcode reported wrong in /proc/cpuinfo

[Brian Inglis]

On 2020-07-16 13:46, Brian Inglis wrote:
> On 2020-07-16 08:56, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> It may be possible that Windows executes a CPUID instruction, and then reads MSR

Intel states CPUID of leaf EAX = 1, so not reading that leaf may not update 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.
-- 
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.]

CPU microcode reported wrong in /proc/cpuinfo

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

Hi All,

In the updated Cygwin (3.1.4), /proc/cpuinfo still reports the microcode version wrong.

Compare:

Cygwin:
$ uname -a
CYGWIN_NT-6.1 xxx 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin

$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 23
model name      : Intel(R) Xeon(R) CPU           X5470  @ 3.33GHz
stepping        : 10
microcode       : 0xFFFFFFF0
cpu MHz         : 3340.000

Linux:
$ cat /proc/cpuinfo
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 23
model name	: Intel(R) Xeon(R) CPU           X5470  @ 3.33GHz
stepping	: 10
microcode	: 0xa0b

I checked the Windows registry, and the data stored there seem to identify the CPU correctly.

HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0
    Component Information    REG_BINARY    00000000000000000000000000000000
    Identifier    REG_SZ    Intel64 Family 6 Model 23 Stepping 10
    Configuration Data    REG_FULL_RESOURCE_DESCRIPTOR    FFFFFFFFFFFFFFFF000000
0000000000
    ProcessorNameString    REG_SZ    Intel(R) Xeon(R) CPU           X5470  @ 3.3
3GHz
    VendorIdentifier    REG_SZ    GenuineIntel
    FeatureSet    REG_DWORD    0x215b3ffe
    ~MHz    REG_DWORD    0xd05
    Update Signature    REG_BINARY    000000000B0A0000
    Update Status    REG_DWORD    0x0
    Previous Update Signature    REG_BINARY    00000000070A0000
    Platform ID    REG_DWORD    0x40

(Intel's CPU ID utility does so as well, "CPU Revision: A0B".)

Any ideas, why Cygwin is off?

Thanks,
Anton

Re: CPU microcode reported wrong in /proc/cpuinfo

[Brian Inglis]

On 2020-05-31 09:07, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> In the updated Cygwin (3.1.4), /proc/cpuinfo still reports the microcode
version wrong.
> Compare:
> 
> Cygwin:
> $ uname -a
> CYGWIN_NT-6.1 xxx 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin
> 
> $ cat /proc/cpuinfo
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 23
> model name      : Intel(R) Xeon(R) CPU           X5470  @ 3.33GHz
> stepping        : 10
> microcode       : 0xFFFFFFF0
> cpu MHz         : 3340.000
> 
> Linux:
> $ cat /proc/cpuinfo
> processor	: 0
> vendor_id	: GenuineIntel
> cpu family	: 6
> model		: 23
> model name	: Intel(R) Xeon(R) CPU           X5470  @ 3.33GHz
> stepping	: 10
> microcode	: 0xa0b
> 
> I checked the Windows registry, and the data stored there seem to identify the CPU correctly.
> 
> HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0
>     Component Information    REG_BINARY    00000000000000000000000000000000
>     Identifier    REG_SZ    Intel64 Family 6 Model 23 Stepping 10
>     Configuration Data    REG_FULL_RESOURCE_DESCRIPTOR    FFFFFFFFFFFFFFFF000000
> 0000000000
>     ProcessorNameString    REG_SZ    Intel(R) Xeon(R) CPU           X5470  @ 3.3
> 3GHz
>     VendorIdentifier    REG_SZ    GenuineIntel
>     FeatureSet    REG_DWORD    0x215b3ffe
>     ~MHz    REG_DWORD    0xd05
>     Update Signature    REG_BINARY    000000000B0A0000
>     Update Status    REG_DWORD    0x0
>     Previous Update Signature    REG_BINARY    00000000070A0000
>     Platform ID    REG_DWORD    0x40
> 
> (Intel's CPU ID utility does so as well, "CPU Revision: A0B".)
> 
> Any ideas, why Cygwin is off?

Thanks for the feedback.
The following indicates the value should be in Update Revision on Intel Core:

	https://www.xf.is/view-cpu-microcode-revision-from-powershell

/proc/cpuinfo currently extracts that from Update Revision but it appears we may
also have to look for Update Signature, perhaps available only on some Windows
releases or Intel CPUs.

Could you please run:

$ head /proc/version

and post the output e.g.:

CYGWIN_NT-10.0-18363 version 3.1.4-340.x86_64 (corinna@calimero) (gcc version
7.4.0 20181206 (Fedora Cygwin 7.4.0-1) (GCC) ) 2020-02-19 08:49 UTC

also:

$ regtool list -v "/proc/registry/HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows
NT/CurrentVersion/" | fgrep =

and post the output e.g.:

SystemRoot (REG_SZ) = "C:\Windows"
BaseBuildRevisionNumber (REG_DWORD) = 0x00000001 (1)
BuildBranch (REG_SZ) = "19h1_release"
BuildGUID (REG_SZ) = "ffffffff-ffff-ffff-ffff-ffffffffffff"
BuildLab (REG_SZ) = "18362.19h1_release.190318-1202"
BuildLabEx (REG_SZ) = "18362.1.amd64fre.19h1_release.190318-1202"
CompositionEditionID (REG_SZ) = "Core"
CurrentBuild (REG_SZ) = "18363"
CurrentBuildNumber (REG_SZ) = "18363"
CurrentMajorVersionNumber (REG_DWORD) = 0x0000000a (10)
CurrentMinorVersionNumber (REG_DWORD) = 0x00000000 (0)
CurrentType (REG_SZ) = "Multiprocessor Free"
CurrentVersion (REG_SZ) = "6.3"
EditionID (REG_SZ) = "Core"
EditionSubManufacturer (REG_SZ) = ""
EditionSubstring (REG_SZ) = ""
EditionSubVersion (REG_SZ) = ""
InstallationType (REG_SZ) = "Client"
InstallDate (REG_DWORD) = 0x5e860beb (1585843179)
ProductName (REG_SZ) = "Windows 10 Home"
ReleaseId (REG_SZ) = "1909"
SoftwareType (REG_SZ) = "System"
UBR (REG_DWORD) = 0x00000344 (836)
PathName (REG_SZ) = "C:\Windows"
ProductId (REG_SZ) = "00325-80150-65794-AAOEM"
DigitalProductId (REG_BINARY) = a4 00 00 00 03 00 00 00
DigitalProductId4 (REG_BINARY) = f8 04 00 00 04 00 00 00
RegisteredOwner (REG_SZ) = "BWI"
RegisteredOrganization (REG_SZ) = ""
InstallTime (REG_QWORD) = 0x01d60907b723cdfd (132303167796006397)

and also:

$ regtool list -v
/proc/registry/HKEY_LOCAL_MACHINE/HARDWARE/DESCRIPTION/System/CentralProcessor/0/

and please post the output verbatim with line breaks included, e.g.

Component Information (REG_BINARY) = 00 00 00 00 00 00 00 00
Identifier (REG_SZ) = "AMD64 Family 21 Model 101 Stepping 1"
Configuration Data (REG_FULL_RESOURCE_DESCRIPTOR) = ?
ProcessorNameString (REG_SZ) = "AMD A10-9700 RADEON R7, 10 COMPUTE CORES 4C+6G "
VendorIdentifier (REG_SZ) = "AuthenticAMD"
FeatureSet (REG_DWORD) = 0x3c3b3dff (1010515455)
~MHz (REG_DWORD) = 0x00000da5 (3493)
Update Revision (REG_BINARY) = 18 61 00 06 00 00 00 00
Update Status (REG_DWORD) = 0x00000001 (1)
Previous Update Revision (REG_BINARY) = 18 61 00 06 00 00 00 00
Platform Specific Field1 (REG_DWORD) = 0x06006118 (100688152)

I'll have to recheck how Linux handles these, and if there are any new AMD/Intel
differences; I'll also have a look in WSL2 for how that gets it, if there are
any differences; see if there is anything from MS, and elsewhere.
I'll have to see if anyone in the family has an Intel box, I can get and put
Cygwin on for checking.

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