[b][/b]
[i][/i]
[u][/u]
[s][/s]
[code][/code]
[quote][/quote]
[spoiler][/spoiler]
[url][/url]
[img][/img]
[video][/video]
Smileys
smile
smile2
spook
alien
zunge
rose
shy
clown
devil
death
flash
sick
heart
idee
frage
blush
smokin
mad
sad
wink
frown
crazy
grin
hmm
laugh
mund
oh
rolling_eyes
lil
oh2
shocked
cool
[mail][/mail]
[pre][/pre]
Farben
[rot][/rot]
[blau][/blau]
[gruen][/gruen]
[orange][/orange]
[lila][/lila]
[weiss][/weiss]
[schwarz][/schwarz]
dash
Posts: 17 | Last online: 06.23.2017
Date registered
11.28.2015
Sex
not specified
    • 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...

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

    • dash has written a new post "CPU Microcode BIOS modding questions/problems" 02.04.2016

      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.

Recipient
dash
Subject:


text:
{[userbook_noactive]}


Xobor Forum Software von Xobor