CentOS - Jan 2018 - /lib/firmware/microcode.dat update on CentOS 6

Dear All,

An update just brought on my CenOS 6 boxes updated microcode.dat files:

  /lib/firmware/microcode.dat

Does anybody know off hand what (how critical) is that, as, if it is 
related to most famous these days trouble with CPU hardware, I will need 
to reboot relevant boxes to have new microcode loaded. But if it is not 
that critical, it can wait till next reboot.

Thanks a lot and apologies for laziness (not looking into details of 
this particular update myself).

Valeri

++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++

On 17/01/18 21:24, Valeri Galtsev wrote:
> Dear All,
> 
> An update just brought on my CenOS 6 boxes updated microcode.dat files:
> 
>  ?/lib/firmware/microcode.dat
> 
> Does anybody know off hand what (how critical) is that, as, if it is 
> related to most famous these days trouble with CPU hardware, I will need 
> to reboot relevant boxes to have new microcode loaded. But if it is not 
> that critical, it can wait till next reboot.
> 
> Thanks a lot and apologies for laziness (not looking into details of 
> this particular update myself).
> 
See:

https://access.redhat.com/errata/RHSA-2018:0093

Red Hat have rolled back the recent microcode updates for Spectre as 
they were causing instabilities in some systems.

Updated microcode was only made available for a relatively small number 
of CPUs so it might be the case that the your microcode was never 
actually updated, hence there is nothing to roll back in the latest 
release, so no need to panic about rebooting. Checking /var/log/messages 
should give you more clues when your microcode was actually last updated 
and allow you to determine if it was before or after the recent Spectre 
fiasco.

On 01/17/2018 03:24 PM, Valeri Galtsev wrote:
> Dear All,
> 
> An update just brought on my CenOS 6 boxes updated microcode.dat files:
> 
> ?/lib/firmware/microcode.dat
> 
> Does anybody know off hand what (how critical) is that, as, if it is
> related to most famous these days trouble with CPU hardware, I will need
> to reboot relevant boxes to have new microcode loaded. But if it is not
> that critical, it can wait till next reboot.
> 
> Thanks a lot and apologies for laziness (not looking into details of
> this particular update myself).
As Phil said, this basically REMOVES the new microcode.dat file and
reverts to the last stable one before the spectre / meltdown update set.

Please see my tweet about this:


https://twitter.com/JohnnyCentOS/status/953734648764477440

For those of you without twitter (WHAT .. who doesn't have twitter :D )

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.

Thanks.
Johnny Hughes

-------------- 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/20180117/f5cca48a/attachment-0001.sig>

> Am 17.01.2018 um 23:22 schrieb Johnny Hughes <johnny at centos.org>:
> 
> On 01/17/2018 03:24 PM, Valeri Galtsev wrote:
>> Dear All,
>> 
>> An update just brought on my CenOS 6 boxes updated microcode.dat files:
>> 
>>  /lib/firmware/microcode.dat
>> 
>> Does anybody know off hand what (how critical) is that, as, if it is
>> related to most famous these days trouble with CPU hardware, I will
need
>> to reboot relevant boxes to have new microcode loaded. But if it is not
>> that critical, it can wait till next reboot.
>> 
>> Thanks a lot and apologies for laziness (not looking into details of
>> this particular update myself).
> 
> As Phil said, this basically REMOVES the new microcode.dat file and
> reverts to the last stable one before the spectre / meltdown update set.
> 
> Please see my tweet about this:
> 
> 
> https://twitter.com/JohnnyCentOS/status/953734648764477440
> 
> For those of you without twitter (WHAT .. who doesn't have twitter :D )
> 
> 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.

BTW: Will the microcode loaded from microcode.dat or from the intel-ucode
directory (for EL6)?

--
LF

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

What about future microcode updates? They come out reasonably regularly
 (2 or 3 times a year) - are RH going to absolve themselves from all
future updates because presumably the next update will also contain the
Spectre fixes?

So, before I re-invent the wheel, does anyone have automation scripts
to do the microcode update? I don't relish the prospect of doing this
manually on a couple of hundred machines. Is it reasonable to grab the
microcode_ctl SRPM and create my own updated RPM to do it?

P.