What's amazing to me is, after "Intel Inside - don't divide" (their 486 debacle), they didn't learn and have a better plan for addressing these kinds of things. ----- Original Message ----- From: "Chris Murphy" <lists at colorremedies.com> To: "centos" <centos at centos.org> Sent: Wednesday, January 24, 2018 12:06:01 PM Subject: Re: [CentOS] /lib/firmware/microcode.dat update on CentOS 6 On Tue, Jan 23, 2018 at 4:26 AM, Johnny Hughes <johnny at centos.org> wrote: > > Here are a couple of posts for our reading pleasure: > > Intel recommends not installing the microcode now: > http://intel.ly/2DsL9qz Except this doesn't mention microcode at all. I can't even tell WTF they're recommending not doing in this doc, it's that badly written. You have to infer, by reading two prior docs, that they're referring to microcode. And then you have to assume that's still what they're referring to when they say: "We recommend that OEMs, cloud service providers, system manufacturers, software vendors and end users stop deployment of current versions." Current versions of what? Microcode? But yes, indeed they appear to have pulled the 20180108 microcode, which was previously set to latest at this link, and it is now reverted to the 20171117 microcode. https://downloadcenter.intel.com/download/27337/Linux-Processor-Microcode-Data-File?v=t What these means for people who have CPUs which were not crashing (rebooting being a new euphemism for crashing) , but saw variant 2 Spectre mitigation with the 20180108 microcode, will lose full mitigation until Intel gets its ducks into a row. *eye roll* > Linus Torvalds agrees: > http://tcrn.ch/2n2mEcA His comments aren't about microcode though. And it also looks like he got IBRS and IBPB confused. The better post on this front is https://lkml.org/lkml/2018/1/22/598 As far as I know, there still is no mitigation for Spectre variant 1. -- Chris Murphy _______________________________________________ CentOS mailing list CentOS at centos.org https://lists.centos.org/mailman/listinfo/centos