| Last online: 04.26.2017
Zitat von plutomaniac im Beitrag #73
Zitat von dash im Beitrag #72
[...] One, is that CPUSVN components are 8-bit (thus, likely SVNs are 8-bit).
Yes I know. It's the same at ME. I have mentioned at the VCN and SVN Extra header fields that only the 1st byte (= 8 bits) is used and the other three are reserved.
That means the field can handle up to 4 SVNs, and should be handled as such until further notice, IMHO. A SVN of zero is the same as no SVN for all intents and purposes (assuming it is unsigned, which is not necessarily a safe assumption, unless either the patents or ME provide clues about this), since it is the least possible security version number...
Zitat von plutomaniac im Beitrag #73
Zitat von dash im Beitrag #72
[...] So, it might not be used by the microcode loader, and yet it might be used/exported by the microcode itself (in this case, SGX).
Interesting idea but if it's used by the CPU after the MCU is successfully loaded, then it stands to reason that any such fields should be included at the encrypted data and not at a visible (but undocumented) header.
Well, yes. A related example: unless Intel is not being as through with this as typical, the processor microcode update process would have to be able to detect and fail due to incompatible processor flags masks, and that information was not present in any of the plaintext data sent to the processor before Skylake. Sure, it was in the documented header, but that header is irrelevant to the processor.
So, such information it is either part of the encrypted sections somehow (either as data, or as a pre-flight check implemented by update-provided opcode), or the hardwired HMAC secret has to be different on processors with incompatible processor flags mask (in which case the microcode update would fail on incompatible processors because the HMAC signature check would fail, even if the RSA keys are the same among all possible processor flags masks, including incompatible ones).
For SGX-related SVNs, which patents make it clear that are implemented as internal microcode-acessible-only registers, the update might have code that sets them from the plaintext header, or from some new parameter table region (encrypted), or even hardwired as ucode instructions inside the update (and thus also encrypted). Since the entire extra plaintext header is signed, fault-injection analysis is likely to be impossible, and there is no way to know unless someone at Intel discloses this information.
Zitat von plutomaniac im Beitrag #71
I was thinking of that mostly at those (supposedly) SVN and VCN fields. Maybe they are used in a similar fashion as in Engine firmware to control invalid downgrades but even if the tests show that the loader does not care about those control numbers, it is very likely that they exist for "book-keeping" purposes, like "metadata" as you said. At the SGX Explained pdf I glimpsed at the term CPUSVN which does not seem related to microcode but shows that these VCN/SVN fields are used by Intel at other places besides Engine firmware.
The SGX paper has quite an interesting information, which you can also get from the referred patent. One, is that CPUSVN components are 8-bit (thus, likely SVNs are 8-bit). The other is that the SGX CPUSVN is derived from concatenation or some other lossless transformation of the SVNs of everything related to the SGX environment (which obviously include microcode components, as well as ME components, among others). So, it might not be used by the microcode loader, and yet it might be used/exported by the microcode itself (in this case, SGX).
"Unsafe shutdown" counter increases means the SSD (NVMe or SATA) was *not* in STANDBY state when it was subject to a power cut. For SATA, that would mean an unplug, or host power off. For NVMe, it *might* also mean the device was set to state D3 (be it D3cold or D3hot), which powers it down while still attached to a powered up PCIe BUS.
Anyway, the possible reasons for this to happen are:
1. O.S. (or driver) did not send STANDBY IMMEDIATE (or the NVMe equivalent) before system power-off / PCIe D3;
2. O.S. (or driver) did not wait for enough time after STANDBY IMMEDIATE (or the NVMe equivalent) before power cut/switch to D3 -- for SATA SSDs, this one IS a MAJOR issue on both Linux and Windows 7/8/10, and yes, it could very well be the problem on NVMe as well. Since it is timing-related, it won't always happen due to combinations of O.S. + platform (BIOS has a say on how much time it takes for a power cut at shutdown...) + SSD + how much work the SSD still had to do;
3. O.S. (or driver) _sent a command to the SSD_ after STANDBY IMMEDIATE/NVMe "standby" equivalent, which forced it back to non-quiescence.
4. SSD firmware bug.
I bet on (2) or (3), since better NVMe drivers seem to fix the issue for most people (this is storage we are talking about, the best drivers are those that do not damage the storage device or increase the risk of data loss. Higher throughput is a fools' measurement of storage driver quality).
That said, ensure you are on the latest SSD firmware, and _always_ report any such bugs to the vendor (SSD vendor, driver vendor and O.S. vendor).
One relatively recent Intel document (or patent, can't recall) I read referred to the microcode patches as "unified patches". They are not just updating the microcode sequencer unit anymore... Also, my theory is that not all of the undocumented header is meaningful to the processor itself, some fields are used by Intel internal tools or processes, or just documentation metadata.
The 8th dword (counting from 1 like you did) is the size of the oldest super-region, which was tested by Ben Hawkes. My best guess is that it contains everything the "classic" microcode updates contained, including whatever "regions" the P6 paper mentioned.
The 6th and 18th dwords have been used as auxiliary sizes, but not as consistently as the 8th dword.
Since Haswell, the 6th dword is the size of the entire update, all regions included. One would need to do a fault-injection analysis on the 6th dword on a recent processor to know if it is relevant to the processor's microcode loader or not -- it might know the size of the extra regions through other means: before Haswell several processors didn't have the 6th dword as the entire update size, but very very likely had extra regions (and on those processors, the 6th dword looked like it was two 16-bit fields of unknown purpose).
The 18th dword does tell a history: it likely is used by Intel tools and not by the processor, at least before Skylake. Before Skylake, it can be zero, or it can be the same as the 8th dword, or, when slightly greater than the 8th dword, it will be the size of the microcode update *including* the noise padding and the extended signature table -- not something the processor itself would care about.
I never paid any attention to the 17th dword, so I did not look for patterns related to it.
BTW, if you didn't do it yet, look for Costan, V. and Devadas, S. "Intel SGX Explained", MIT, 2016. It explains a lot of how Intel processor microcode works (because SGX is almost entirely done in ucode), and its references have several relevant patents which explain things further.
Zitat von plutomaniac im Beitrag #67
What paper is this information found at?
Page 16 of CHEN, AHN, "Security Analysis of x86 Processor Microcode", 2014-12-11. Search the article's name in duckduckgo.
Zitat von plutomaniac im Beitrag #64
Any useful comments, suggestions, improvements etc are always welcome.
To me, it looks like the analysis for the 5th dword is partially incorrect.
Please reread Ben Hawkes' paper, he mentions the 64th *bit* on his observation number 5. This would be bit 0 of the field *right after* the "magic" field that is always 0xa1, i.e. the field that has a constant 0x00020001 value in every microcode update seen in public updates and BIOSes thus far. This also makes a lot more sense when you read the full text in Ben's paper, where he says the bit was initially "1" and things got strange when it was changed to "0", i.e. the dword was being changed from 0x00020001 to 0x00020000.
Thus, messing with the 5th dword ("maybe VCN" field) results in a normal failure per Ben's testing -- it is just a normal failure due to a bad signature.
All of these microcode updates have multiple "regions" inside -- someone at intel has publicly stated that according to some of the SGX/microcode security papers. Let's call the thing we send to the processor a MCU, to differentiate it from one of its "regions" that actually changes the processor's microcode translation unit (let's call that specific region, the "microcode patch").
That field might be the version of the "microcode patch" region, i.e. of the specific subset of the processor firmware that is used by its microcode translation unit. A MCU has been documented to also have runnable microcode and opcode regions that the processor executes when applying the update, for example. If you change one of these other regions, but not the "microcode patch", you would not have to update the microcode patch version field.
Ben Hawkes did not really test *downgrades* and that's a test that can be easily engineered to show if this field can work as a downgrade barrier or not.
Be very careful with microcode 0x206c2 if your BIOS microcode is earlier than 0x15 on any machine with Intel TXT, or its Xeon version (I fail to recall the name of TXT for servers).
Starting from either 0x206c2 revision 0x14 or revision 0x15 (don't know which), the microcode update permanently enforces a newer version of the Intel TXT SINIT ACM (which can be downloaded from Intel as well, but I have no idea how to *install* that into the BIOS/UEFI) by modifying the contents of the TPM(!!!), so while biosmodding to update that microcode, you are supposed to *always*replace the ACM modules with up-to-date ones on any Intel-TXT-enabled BIOS. The 0x206c2 microcode update is likely safe on systems lacking Intel TXT, but I never heard of any test results, so I wouldn't know how safe it is. THE CHANGES MADE BY THIS MICROCODE UPDATE CANNOT BE REVERTED BY JUST DOWNGRADING THE BIOS, YOU HAVE BEEN WARNED.
As for 0x1067A and 0x10676, the microcode payload contents for everything 0x10676 are actually equal byte-to-byte for the same revision of the microcode, if you ignore the headers. The same is true for 0x1067A. So, all the production platforms actually use the same payload (the real microcode contents, when you remove the header). No idea why Intel segmented the microcode updates in server (0x44), and desktop (0x91), and sometimes even segmented it by socket. They stopped doing this kind of crap soon after that...
The latest 106A4 (Core i7 Bloomfield C0/C1) and 106A5 (Core i7 Bloomfield D0 and also Xeon 3500/5500 D0) are rev 0x13 and rev 0x1B respectively.
These two microcode releases (as well any microcode updates for Westmere, Core2, Core Solo, etc from 2015-06 to 2015-08) are relevant because they have a microcode-level fix for the "memory sinkhole" LAPIC security hole.
I've been running 106A5 rev 0x1B for a long time now on a Supermicro board with a Xeon X5550. This motherboard has the LAPIC at the proper, standard address of 0xfee00000. If a Linux boot reports anything different from "ACPI: Local APIC address 0xfee00000" for a motherboard, these microcode updates *might* cause boot issues depending on just how nice Intel decided to be about denying LAPIC address changes in the new microcode.
I'd very much like to know if you have a system that boots successfully with these microcodes and has a local apic address that is *not* 0xfee00000...
Since signature 0x806e9 is for KabyLake U/Y, anyone has any idea what signature 0x506e8 would be for? microcode for 0x506e8 is showing up on some Skylake-H/S motherboard BIOSes, so it is an ES part for something that would fit on the same socket as Skylake-H/S...
any chances of sourcing the related update for signature 206d7 ?
It depends on what you run. You may need up-to-date Haswell-E microcode for stable operation if you run any of:
1. virtualization (such as Virtualbox or VMware)
2. Any software that does hardware lock elision or transactional memory (good luck find this beforehand)
3. You are not extremely lucky ;-)
Also, if you get MCEs (machine check errors) or misterious hangs/crashes. Also, if you cannot install (from scratch) Windows 10 or Linux, because it crashes/hangs during installation.
i.e. yes, you do need the latest Haswell-E microcode if you want your rig to run anywhere close to stable.