From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) by sourceware.org (Postfix) with ESMTPS id C70443857C58 for ; Thu, 16 Jul 2020 19:47:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C70443857C58 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=SystematicSw.ab.ca Authentication-Results: sourceware.org; spf=none smtp.mailfrom=brian.inglis@systematicsw.ab.ca Received: from [192.168.1.104] ([24.64.172.44]) by shaw.ca with ESMTP id w9qMjiXL062brw9qNjFGqr; Thu, 16 Jul 2020 13:46:59 -0600 X-Authority-Analysis: v=2.3 cv=LKf9vKe9 c=1 sm=1 tr=0 a=kiZT5GMN3KAWqtYcXc+/4Q==:117 a=kiZT5GMN3KAWqtYcXc+/4Q==:17 a=IkcTkHD0fZMA:10 a=QyXUC8HyAAAA:8 a=akje89l3nSV0mwZZYFYA:9 a=QEXdDO2ut3YA:10 Reply-To: cygwin@cygwin.com Subject: Re: CPU microcode reported wrong in /proc/cpuinfo To: cygwin@cygwin.com References: <5f880838-55ad-6f6e-33a6-6a57d7ae9c92@SystematicSw.ab.ca> <68eea787-9cde-d6ed-499b-61dfc036adff@SystematicSw.ab.ca> From: Brian Inglis Autocrypt: addr=Brian.Inglis@SystematicSw.ab.ca; prefer-encrypt=mutual; keydata= mDMEXopx8xYJKwYBBAHaRw8BAQdAnCK0qv/xwUCCZQoA9BHRYpstERrspfT0NkUWQVuoePa0 LkJyaWFuIEluZ2xpcyA8QnJpYW4uSW5nbGlzQFN5c3RlbWF0aWNTdy5hYi5jYT6IlgQTFggA PhYhBMM5/lbU970GBS2bZB62lxu92I8YBQJeinHzAhsDBQkJZgGABQsJCAcCBhUKCQgLAgQW AgMBAh4BAheAAAoJEB62lxu92I8Y0ioBAI8xrggNxziAVmr+Xm6nnyjoujMqWcq3oEhlYGAO WacZAQDFtdDx2koSVSoOmfaOyRTbIWSf9/Cjai29060fsmdsDLg4BF6KcfMSCisGAQQBl1UB BQEBB0Awv8kHI2PaEgViDqzbnoe8B9KMHoBZLS92HdC7ZPh8HQMBCAeIfgQYFggAJhYhBMM5 /lbU970GBS2bZB62lxu92I8YBQJeinHzAhsMBQkJZgGAAAoJEB62lxu92I8YZwUBAJw/74rF IyaSsGI7ewCdCy88Lce/kdwX7zGwid+f8NZ3AQC/ezTFFi5obXnyMxZJN464nPXiggtT9gN5 RSyTY8X+AQ== Organization: Systematic Software Message-ID: <04c2c0ea-1e27-508b-c054-a5ad8e1da240@SystematicSw.ab.ca> Date: Thu, 16 Jul 2020 13:46:58 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfGF6VVjXCNK9NCbIslZmEqSc2y/sm5BR/1mRhW1PNoLpGbzKaMhdtYMTUHeqihXUMSNYFjyrW/NtUGGMOPLUz9+acToRV0uwQNeKjoMbUPMB9B5bIWAE 7PMXcr8FYaDp9X0YB4rD8MXaRoCY3zG/5QrrJEyNsyZG1iuirzurf/oIJLPexf6H6gGSCCckUe2K2Q== X-Spam-Status: No, score=-8.7 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 19:47:02 -0000 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.]