A new version of microcode updates has been released. There should be new updates for some older generations of Intel CPUs to mitigate some of the Spectre attack variants (V1, I believe?). It is expected to be the latest release for older CPUs. The following document describes the new revisions in details: https://newsroom.intel.com/wp-content/uploads/sites/11/2018/04/microcode-update-guidance.pdf
We are working on this, however, this isn't a normal bump. Microcode updates for BDX-ML platform, aka Xeon E5/E7 v4 or Core i7-69xx/68xx, require an updated microcode loader in kernel which is only present in >=4.14.34. Loading such microcodes with unpatched loader might result in unexpected system behavior.
I've proposed a pull request for a bumped ebuild. https://github.com/gentoo/gentoo/pull/8532
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=eb9036f6f998c91c6bc021f73bc10ca1b5240ae7 commit eb9036f6f998c91c6bc021f73bc10ca1b5240ae7 Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2018-05-23 18:02:28 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2018-05-23 18:24:36 +0000 sys-firmware/intel-microcode: Bump Ebuild changes: =============== - Based on Intel's microcode tarball from 2018-04-25. - Added 210+ additional microcode updates (for production, no beta release!), which are signed by Intel and publicly available but are not distributed via Intel's microcode tarball for marketing/product phase out reasons. You can prevent the usage of these microcode updates and stick with content from Intel's official release tarball via new "vanilla" USE flag. - Blacklisted microcode 0x000604f1 aka 06-4f-01 aka CPUID 406F1 which requires a newer microcode loader in kernel which is only available in kernel >=4.14.34. It is blacklisted because loading via older loader could crash the system. A news item with instructions will follow. Closes: https://github.com/gentoo/gentoo/pull/8532 Bug: https://bugs.gentoo.org/654638 Package-Manager: Portage-2.3.38, Repoman-2.3.9 sys-firmware/intel-microcode/Manifest | 2 + .../intel-microcode-20180426.ebuild | 129 +++++++++++++++++++++ sys-firmware/intel-microcode/metadata.xml | 1 + 3 files changed, 132 insertions(+)
Added, but without keywords. We will have to create documentation and a news item before we can keyword due to the risk to crash systems using latest Intel processors with <linux-4.14.34.
> - Added 210+ additional microcode updates (for production, no beta > release!), > which are signed by Intel and publicly available but are not distributed > via Intel's microcode tarball for marketing/product phase out reasons. > You can prevent the usage of these microcode updates and stick with > content from Intel's official release tarball via new "vanilla" > USE flag. Dear Thomas and team, thank you; your's quite better of course - I'll switch to this. Guido
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=04384b5c8adb359c5a828ce1c34b4827122e917b commit 04384b5c8adb359c5a828ce1c34b4827122e917b Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2018-05-24 12:29:59 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2018-05-24 12:30:14 +0000 sys-firmware/intel-microcode: Split env var into MICROCODE_... ...{BLACKLIST,SIGNATURES} Especially now, since we are shipping a lot of microcodes, initramfs can become very large and users might want to install only specific microcode updates for their processor via MICROCODE_SIGNATURES="-S" option. However, this would overwrite our default BLACKLIST. To allow users to use "-S" option without the burden to manually maintain a BLACKLIST, we introduced a new MICROCODE_BLACKLIST environment variable to split things. In addition, there was a typo is previous blacklisted signature which was corrected to blacklist the correct microcode. Bug: https://bugs.gentoo.org/654638 Package-Manager: Portage-2.3.38, Repoman-2.3.9 ...6.ebuild => intel-microcode-20180426-r1.ebuild} | 49 ++++++++++++++-------- 1 file changed, 31 insertions(+), 18 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3eacfe4274c5d0c8a69911df89525324697c6328 commit 3eacfe4274c5d0c8a69911df89525324697c6328 Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2018-05-29 23:14:42 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2018-05-29 23:15:11 +0000 sys-firmware/intel-microcode: Add "minimal" USE flag Due to previous change (commit eb9036f6f998c91c6bc021f73bc10ca1b5240ae7), this package can become very large (or the resulting initramfs). While the already introduced environment variable "MICROCODE_SIGNATURES" is allowing you to set iucode_tool's "--scan-system" parameter to only install ucode(s) supported by the currently available (=online) processor(s), this doesn't work for binary package user(s). The now added "minimal" USE flag (enabled by default) will set "--scan-system" parameter for you. This will still allow you to select/blacklist ucode(s) for all your hosts on your central build host using the "MICROCODE_SIGNATURES" variable like before while giving each host the opportunity to only install really supported ucode(s) which will reduces the file size of the resulting initramfs. Bug: https://bugs.gentoo.org/654638 Package-Manager: Portage-2.3.40, Repoman-2.3.9 ...1.ebuild => intel-microcode-20180426-r2.ebuild} | 58 ++++++++++++++++++++-- sys-firmware/intel-microcode/metadata.xml | 1 + 2 files changed, 55 insertions(+), 4 deletions(-)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8c9da1ab3f5a74c3724cdfeb383006eb603aa65d commit 8c9da1ab3f5a74c3724cdfeb383006eb603aa65d Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2018-05-30 12:56:38 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2018-05-30 12:56:57 +0000 sys-firmware/intel-microcode: bump Removed microcodes (due to updates): - sig 0x000806e9, pf_mask 0xc0, 2018-01-21, rev 0x0084, size 98304 - sig 0x000906e9, pf_mask 0x2a, 2018-01-21, rev 0x0084, size 98304 Added microcodes: - sig 0x000806e9, pf_mask 0xc0, 2018-03-24, rev 0x008e, size 98304 - sig 0x000906e9, pf_mask 0x2a, 2018-03-24, rev 0x008e, size 98304 - sig 0x000906ec, pf_mask 0x22, 2018-02-19, rev 0x0084, size 96256 Closes: https://bugs.gentoo.org/654638 Package-Manager: Portage-2.3.40, Repoman-2.3.9 sys-firmware/intel-microcode/Manifest | 2 +- ...l-microcode-20180426-r2.ebuild => intel-microcode-20180527.ebuild} | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-)
<QA hat on> Please revert this. This is a horrible idea that shouldn't have been committed in the first place. 1. USE=minimal has a well-defined meaning -- it is supposed to disable non-important features. Automagically guessing what needs to be installed is not a valid case of USE=minimal. 2. Enabling this by default is a *horrible* *breaking* idea. It just means that as a part of upgrade files may suddenly disappear which is not nice. Even if you think your logic covered all the corner cases, you're still breaking stuff for unsuspecting people with corner cases you didn't think of. 3. Installing an empty package and silently pretending that everything went a-ok is not fine. </QA hat on> (CC-ing Patrick who experienced the breakage first-hand)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8edea0b06510066c10fef7270d196b5ec1e6d056 commit 8edea0b06510066c10fef7270d196b5ec1e6d056 Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2018-05-30 22:18:55 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2018-05-30 22:41:18 +0000 sys-firmware/intel-microcode: rev bump to address QA problem - We now install splitted ucode(s) into the correct directory. - Fixed an issue when emerge failed when no microcode was selected. - "minimal" USE flag was renamed to "hostonly" and disabled per default to avoid confusion. - Additional sanity checks were added to show a warning if no microcode update was installed (can be the case when user set "hostonly" USE flag or uses MICROCODE_SIGNATURES environment variable). Closes: https://bugs.gentoo.org/654638 Package-Manager: Portage-2.3.40, Repoman-2.3.9 ...7.ebuild => intel-microcode-20180527-r1.ebuild} | 42 ++++++++++++++++------ sys-firmware/intel-microcode/metadata.xml | 2 +- 2 files changed, 32 insertions(+), 12 deletions(-)
I am at two minds of whether I should comment this or not, but since your actions could have far reaching consequences, I'd better even if I don't use gentoo myself. First things first: there is no such a thing as "production" intel microcode (in MCExtract/UBU/microcode db terms) being "safe" for *general* deployment through an operating system update package. A positive revision number (which is what MCExtract/microcode db has tagged as "production") just means it could be a *candidate* for being considered "stable/production" microcode if it proves itself stable *AND* gets deployed with the required revision of the platform support package (aka the BIOS/UEFI gets updated to be compatible when required). It doesn't even mean it is for public consumption: non-negative microcode updates for some engineering steppings have been observed in the wild (and are in that microcode repository). The only way to know what the *current* status of a given microcode update is behind an NDA barrier with the notable exception of the (now already somewhat outdated) information in the Intel slides related to spectre-v2 updates, so I am rightfully assuming whomever compiled this list of production microcode updates did _NOT_ have access to that information (for the record: I don't have access to that information either). And it is rather common that a production *current* microcode update also required a production *current* firmware to work well at the time it was deployed. THIS is not in any public microcode status table, and it is the technical reason some of the Spectre-v2 microcode updates are not present in the public distribution yet (e.g.: 0x206c2, 0x106a5, 0x106e5...). It is not always going to cause trouble, but whether it will or not do it depends on how outdated the user's firmware is... Now, several years ago, Intel indeed would remove good, safe microcode updates for no other reason than their respective processors being long in end-of-life status. This has not happened for several years, with the notable exception of signature 0x106e4 for the Embedded Nehalem Xeon EC35xx/EC55xx "Jasper Forest" -- and that public microcode update was in a strangely "frozen" state when compared with the other Nehalem processors, anyway). IOW: you can assume microcode that has been shipped *unchanged* for several years in the public microcode distribution, and then got removed, to be "safe". But that reasoning certainly does not apply to microcode updates that were shipped for just one public release and then removed (in fact, the opposite should be assumed: they're likely to be "unsafe"). And nothing should be assumed about the safety of microcode updates that were never in the public distribution, unless you know better about a specific update from other information channels. I'd strongly recommend that you either don't ship microcode updates that have never been in the public distribution, or that you at the very least *never* install those by default, unless the user has done an informed opt-in.
(In reply to Henrique de Moraes Holschuh from comment #11) > I am at two minds of whether I should comment this or not, but since your > actions could have far reaching consequences, I'd better even if I don't use > gentoo myself. > > First things first: there is no such a thing as "production" intel microcode > (in MCExtract/UBU/microcode db terms) being "safe" for *general* deployment > through an operating system update package. > > A positive revision number (which is what MCExtract/microcode db has tagged > as "production") just means it could be a *candidate* for being considered > "stable/production" microcode if it proves itself stable *AND* gets deployed > with the required revision of the platform support package (aka the > BIOS/UEFI gets updated to be compatible when required). > > It doesn't even mean it is for public consumption: non-negative microcode > updates for some engineering steppings have been observed in the wild (and > are in that microcode repository). > > The only way to know what the *current* status of a given microcode update > is behind an NDA barrier with the notable exception of the (now already > somewhat outdated) information in the Intel slides related to spectre-v2 > updates, so I am rightfully assuming whomever compiled this list of > production microcode updates did _NOT_ have access to that information (for > the record: I don't have access to that information either). > > And it is rather common that a production *current* microcode update also > required a production *current* firmware to work well at the time it was > deployed. THIS is not in any public microcode status table, and it is the > technical reason some of the Spectre-v2 microcode updates are not present in > the public distribution yet (e.g.: 0x206c2, 0x106a5, 0x106e5...). It is not > always going to cause trouble, but whether it will or not do it depends on > how outdated the user's firmware is... > > Now, several years ago, Intel indeed would remove good, safe microcode > updates for no other reason than their respective processors being long in > end-of-life status. This has not happened for several years, with the > notable exception of signature 0x106e4 for the Embedded Nehalem Xeon > EC35xx/EC55xx "Jasper Forest" -- and that public microcode update was in a > strangely "frozen" state when compared with the other Nehalem processors, > anyway). > > IOW: you can assume microcode that has been shipped *unchanged* for several > years in the public microcode distribution, and then got removed, to be > "safe". But that reasoning certainly does not apply to microcode updates > that were shipped for just one public release and then removed (in fact, the > opposite should be assumed: they're likely to be "unsafe"). And nothing > should be assumed about the safety of microcode updates that were never in > the public distribution, unless you know better about a specific update from > other information channels. > > I'd strongly recommend that you either don't ship microcode updates that > have never been in the public distribution, or that you at the very least > *never* install those by default, unless the user has done an informed > opt-in. (the latest ones for signatures 0x80xxx and 0x90xxx are likely to be safe, if you managed to test them and they caused no issues, though. But you'd have to test them with SSBD/spectre-v4 support active in the operating system, and specifically stress *that* to know for sure). And revision 0x8e is already outdated, there is 0x94 in the wild for one of them, so one can't even be really sure issues were not found on those...
Any microcode update needs testing. There's even _zero guarantee_ that any microcode update contained in Intel's official tarball _or_ shipped as part of your BIOS/UEFI update, works (best example was the first batch of pulled Spectre fixes: Intel said they tested it a lot before sharing with partners, then they tested with partners... then they released... and then they pulled it). > And it is rather common that a production *current* microcode update also required a production *current* firmware to work well at the time it was deployed. That's right. That was the reason why a Xeon microcode update, _distributed as part of Intel's microcode tarball_, was pulled in 2017 in most commercial distribution because if it was loaded on an outdated firmware it caused problems. But this is Gentoo. We expect that you know to some point what you are doing. And like said, _any_ microcode update could cause problems, the intel-microcode package isn't a package you should ever blindly install. If you care that much, do _NOT_ use that package at all. Stick with microcode updates which you only apply as part of your firmware update. Then you have a vendor you can blame. And because you are only using hardware which is still being maintained with an active support contract, that wouldn't be a problem for you, right? ;) Hiding the additional microcode updates which aren't part of Intel's tarball behind a USE flag so that the user would have to opt-in would be a false sense of quality/security understanding: Like said, _any_ microcode update can cause problems. Saying that there's a higher risk by using any microcode update which isn't part of Intel's tarball isn't true. However, you can opt-out. In addition, we believe that we have a very good insight into non-publicly available information regarding microcode updates. If we will ever get to know about a problem, we will take action and blacklist. I cannot share more details. And in the meantime we are able to protect/help users (especially notebook users) who for example don't have access to regular firmware/microcode updates because they didn't buy a product from a big player like Dell or Lenovo with business-class support... If you'd like to continue discussing please ping me on IRC or file an own bug.
>> But this is Gentoo. We expect that you know to some point what you are doing ... >> In addition, we believe that we have a very good insight into non-publicly available information regarding microcode updates. Well, then I have no further reason to discuss this, do I? I still think one would be better served with a safer approach for the benefit of the users that, no matter how advanced, won't "know better" about something as obscure as this, or how to handle it should it misbehave. But that's just MHO.
