[CentOS] /lib/firmware/microcode.dat update on CentOS 6

[Johnny Hughes]

On 01/22/2018 10:06 AM, Valeri Galtsev wrote:
> 
> 
> On 01/22/18 09:08, Johnny Hughes wrote:
>> On 01/18/2018 09:42 AM, Valeri Galtsev wrote:
>>>
>>>
>>> On 01/18/18 03:41, Pete Biggs wrote:
>>>>
>>>>> Look at:
>>>>>
>>>>> https://t.co/6fT61xgtGH
>>>>>
>>>>> Get the latest microcode.dat file from here:
>>>>>
>>>>> https://t.co/zPwagbeJFY
>>>>>
>>>>> See how to update the microcode from the links at the bottom of this
>>>>> page:
>>>>>
>>>>> https://t.co/EOgclWdHCw
>>>>>
>>>>> An before anyone asks .. I have no idea why Red Hat chose this path,
>>>>> they did.  It doesn't matter if I (or anyone else) agrees with the
>>>>> decision.  It is what it is.
>>>>>
>>>> **I'm not blaming you.**
>>>>
>>>> But can I just clarify. We have to *manually* install the microcode
>>>> update an EL7 in order to be protected against Spectre? EL6 as well?
>>>>
>>>> Presumably this is to remove RH from the loop and to stop people
>>>> blaming them - i.e. this is between Intel and the customer, it's
>>>> nothing to do with them.
>>>
>>> I bet you are right. I was going to rant about that... then it occurred
>>> to me that class action against Intel (didn't hear about AMD though) is
>>> quite likely, so, indeed, RedHat does not want to be even mentioned in
>>> it, which will be unfair, especially after RedHat putting effort into
>>> fixing somebody's else crap.
>>>
>>
>> It isn't about washing hands, lawsuits, or soeoen else's stuff.  It is
>> about broken microcode updates.
>>
>> The code from intel was broken .. causing several CPUs not to boot after
>> update.  That (and only that) is why they were pulled.
>>
>> Users MUST individually QA the microcode for their individual CPUs, OEM
>> Frimware, chipset etc.
>>
>> The issue here is that the microcode broke peoples machines .. therefore
>> it had to be rolled back.  All the other discussion is full and total BS.
>>
>> It is likely ONCE all the microcode updates are tested and completely
>> working that Red Hat will again include it in the microcode_ctl RPM ..
>> but that can't put stuff in there that is breaking machines.
>>
>> While things are beuing released as QA quality, they are going to have
>> to be done individually by admins .. that's just how it is.
>>
> 
> Thanks Johnny, for correcting my wild guess which was wrong, and the
> fact that my guess was wrong I realized after reading your other post!
> 
> As with everything else the end user pays one way or another. :-(

Here are a couple of posts for our reading pleasure:

Intel recommends not installing the microcode now:
http://intel.ly/2DsL9qz

Linus Torvalds agrees:
http://tcrn.ch/2n2mEcA


So, wait on those microcode updates for a while.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos/attachments/20180123/b406a09b/attachment.sig>