Posts: 24 | Last online: 08.20.2017
Date registered
not specified
    • Just as a sidenote, for those that always wondered what AMD x86 microcode used to look like from the inside (really!):

      Reverse Engineering x86 Processor Microcode.

      Microcode is an abstraction layer on top of the physical components of a CPU and present in most general-purpose CPUs today. In addition to facilitate complex and vast instruction sets, it also provides an update mechanism that allows CPUs to be patched in-place without requiring any special hardware. While it is well-known that CPUs are regularly updated with this mechanism, very little is known about its inner workings given that microcode and the update mechanism are proprietary and have not been throughly analyzed yet.

      In this paper, we reverse engineer the microcode semantics and inner workings of its update mechanism of conventional COTS CPUs on the example of AMD’s K8 and K10 microarchitectures. Furthermore, we demonstrate how to develop custom microcode updates. We describe the microcode semantics and additionally present a set of microprograms that demonstrate the possibilities offered by this technology. To this end, our microprograms range from CPU-assisted instrumentation to microcoded Trojans that can even be reached from within a web browser and enable remote code execution and cryptographic implementation attacks.

    • That explains why "Kaby Lake-X" is marked as "not affected" by the hyper-threading bug in Intel's docs: due to the platform mask/platform id bits in the microcode, the minimum microcode version that will work for those chips already has the fix...

    • I see. I had not made the connection between the file names and where those dumps came from!

      Thanks. And Thanks to Plutomaniac for the confirmation as well!

    • Yeah, but is microcode 0x5e for Kaby Lake the one in the most up-to-date BIOS of the Skylake Intel NUCs?

      So far, it is pure speculative that revision 0x5e could fix the KBL095 (hyper-threading) bug in kaby lake, because that speculation is only based on the microcode date being close to the Skylake revision 0xba microcode.

      If someone confirms which revision of the microcode is in the latest Intel Kaby Lake NUC BIOS, that would tie that revision with the Intel Changelog for the Intel NUC BIOS update, which explicitly mentions "update microcode to fix hyper-threading bug"...

    • People using UBU (which are quite common in this forum ;-) ) to update UEFI with the newest microcode updates for Skylake are already protected from SKL150, and don't have to fear anything.

      Actually, this is likely true for Kaby Lake too, since UBU has 0x906E9 and 0x806e9 microcode updates that are dated new enough to have the KBL095 fix. This is not confirmed, because nobody has posted which microcode revisions are present in the latest BIOS updates for the Intel NUCs (updated like three or four days ago with the Kaby Lake fix)... but confirmation should happen sometime soon.

    • Be careful about that microcode 0x206c2 if the motherboard supports vPro/Intel TXT.

      Read post #52 and later posts in this thread, it might save you from a bricked motherboard.

      If the motherboard DOES have Intel TXT/vPro, either ensure (or also update) the SINIT ACM module (UBU won't do it, read post #53 and do it by hand, SINIT ACM download is at https://software.intel.com/en-us/article...ion-technology/ ), or disable Intel TXT on BIOS *before* updating, and *pray* that it is enough (never enable it again after that).

      If it bricks, reflashing the original BIOS *will not debrick it*. Your only hope would be to flash a BIOS *with the updated ACM*, or somehow disable the BIOS use of Intel TXT.

    • Debian has updated their intel-microcode package, and its changelog has some relevant details:

      * New upstream microcode datafile 20170511
      + Updated Microcodes:
      sig 0x000306c3, pf_mask 0x32, 2017-01-27, rev 0x0022, size 22528
      sig 0x000306d4, pf_mask 0xc0, 2017-01-27, rev 0x0025, size 17408
      sig 0x000306f2, pf_mask 0x6f, 2017-01-30, rev 0x003a, size 32768
      sig 0x000306f4, pf_mask 0x80, 2017-01-30, rev 0x000f, size 16384
      sig 0x00040651, pf_mask 0x72, 2017-01-27, rev 0x0020, size 20480
      sig 0x00040661, pf_mask 0x32, 2017-01-27, rev 0x0017, size 24576
      sig 0x00040671, pf_mask 0x22, 2017-01-27, rev 0x0017, size 11264
      sig 0x000406e3, pf_mask 0xc0, 2017-04-09, rev 0x00ba, size 98304
      sig 0x000406f1, pf_mask 0xef, 2017-03-01, rev 0xb000021, size 26624
      sig 0x000506e3, pf_mask 0x36, 2017-04-09, rev 0x00ba, size 98304
      + This release fixes undisclosed errata on the desktop, mobile and server processor models from the Haswell, Broadwell, and Skylake families, including even the high-end multi-socket server Xeons
      + Likely fix the TSC-Deadline LAPIC errata (BDF89, SKL142 and similar) on several processor families
      + Fix erratum BDF90 on Xeon E7v4, E5v4(?) (closes: #862606)
      + Likely fix serious or critical Skylake errata: SKL138/144, SKL137/145, SLK149
      * Likely fix nightmare-level Skylake erratum SKL150. Fortunately, either this erratum is very-low-hitting, or gcc/clang/icc/msvc won't usually issue the affected opcode pattern and it ends up being rare.
      SKL150 - Short loops using both the AH/BH/CH/DH registers and the corresponding wide register *may* result in unpredictable system behavior. Requires both logical processors of the same core (i.e. sibling hyperthreads) to be active to trigger, as well as a "complex set of micro-architectural conditions"

      Basically: everyone should update their microcode for stability, this recent batch of updates is fixing some nasty issues... including the ones not part of the Intel public release (such as Kaby Lake).

      EDIT by Fernando: Put the changelog into a spoiler (to save space within this voluminous thread)

    • Meh. The new intel microcode release has a "releasenote" file... unfortunately, everything they tell you to do there is wrong and actively harmful , other than the information at the very beginning which gives some hint about to which processor the microcode updates apply.

      It is weird when modding a BIOS is safer than following Intel's instructions on how to apply microcode updates

    • Zitat von plutomaniac im Beitrag #2949
      New Intel Linux Microcode file from 11/05/2017

      Direct link to the new release: https://downloadcenter.intel.com/downloa...ocode-Data-File

      Apparently, they did no more than patting the head of the <...> that screwed up the previous release, so he/she just went and did it again. Release 2017-05-11 is marked as "previously released", and has a wrong release date. Last time, it took about a month for someone to clean up after the <...>... and lots of Linux distros did not notice the new file was out for a month because of that.

      @plutomaniac: which method are you using to track new releases from Intel? You are better at noticing them than Intel's search engine

    • dash has written a new post "Intel Management Engine: Drivers, Firmware & System Tools" 05.05.2017

      HP is special. This *will* look fanboyish[1], but the fact is that HP _typically_ takes far more care of their server and corporate lines than any other vendor. They are the only ones that shipped firmware updates containing certain microcode updates (that cannot be found *anywhere else*) fixing security issues on old Intel processors such as the Core Duo, and Core2. Such processors were used on some of their 6-year-old corporate desktop lines, and it does look like it was HP that requested that Intel produce such updates for the older SKUs, even when they were already listed as EOL according to Intel ARK.

      So, yes, you can and should expect HP corporate machines (servers/desktops) to show up with firmware you won't find anywhere else.

      [1] I don't actually like HP hardware because it does way too much behind your back in SMM (massive headache for HPC, and low-latency + low-jitter work), and it also has a tendency of being "special" in very bad ways.

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



Xobor Forum Software von Xobor