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

On 01/18/18 11:31, Matthew Miller wrote:
> On Thu, Jan 18, 2018 at 11:01:18AM -0500, Pete Geenhuizen wrote:
>> Do we update the microcode now or do we wait until the latest
>> microcode_ctl rpm is available and then tackle this issue?
> Check with your hardware vendor for BIOS/EFI firmware updates. Apply
> those.
>
>
>
Thanks for the reply, but you missed what I was asking.? I've already 
downloaded the appropriate files from the links that Johnny provided in 
a previous posting.
My question is, do we wait until the latest microcode_ctl rpm is 
installed or do it now?? My concern is that if I do it now the new rpm 
might undo what I've done.

-- 
Unencumbered by the thought process.
  -- Click and Clack the Tappet brothers


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

On Thu, Jan 18, 2018 at 11:45:42AM -0500, Pete Geenhuizen
wrote:
> >>Do we update the microcode now or do we wait until the latest
> >>microcode_ctl rpm is available and then tackle this issue?
> >Check with your hardware vendor for BIOS/EFI firmware updates. Apply
> >those.
> >
> Thanks for the reply, but you missed what I was asking.? I've
> already downloaded the appropriate files from the links that Johnny
> provided in a previous posting.
> My question is, do we wait until the latest microcode_ctl rpm is
> installed or do it now?? My concern is that if I do it now the new
> rpm might undo what I've done.
It does not matter. The microcode_ctl package contains CPU firmware
that is loaded at by the kernel early in the boot process if it's newer
than the one provided by the system firmware/BIOS. It is never
permanently stored in NVRAM or anything ? it's loaded at each boot.

You should get a BIOS/EFI firmware update from your hardware vendor
which includes updated microcode. Then, you'll get the IBRS-capable
microcode at boot, every boot. This makes microcode_ctl moot.

Read more about this here: https://access.redhat.com/solutions/3315431


-- 
Matthew Miller
<mattdm at fedoraproject.org>
Fedora Project Leader

On 18/01/18 18:55, Matthew Miller wrote:
> On Thu, Jan 18, 2018 at 11:45:42AM -0500, Pete Geenhuizen wrote:
>>>> Do we update the microcode now or do we wait until the latest
>>>> microcode_ctl rpm is available and then tackle this issue?
>>> Check with your hardware vendor for BIOS/EFI firmware updates.
Apply
>>> those.
>>>
>> Thanks for the reply, but you missed what I was asking.? I've
>> already downloaded the appropriate files from the links that Johnny
>> provided in a previous posting.
>> My question is, do we wait until the latest microcode_ctl rpm is
>> installed or do it now?? My concern is that if I do it now the new
>> rpm might undo what I've done.
> 
> It does not matter. The microcode_ctl package contains CPU firmware
> that is loaded at by the kernel early in the boot process if it's newer
> than the one provided by the system firmware/BIOS. It is never
> permanently stored in NVRAM or anything ? it's loaded at each boot.
> 
Hence, by my understanding, there should not be any permanent damage 
should you get a 'bad' microcode update, either from Intel or Red Hat, 
that prevents the system from booting. Presumably one should still 
always be able to boot the machine from a rescue disk, mount the fs and 
either delete the offending microcode or uninstall the microcode_ctl 
package to allow the system to boot again. This should not result in a 
'bricked' permanently unrecoverable system.

On 01/18/18 12:55, Matthew Miller wrote:
> On Thu, Jan 18, 2018 at 11:45:42AM -0500, Pete Geenhuizen wrote:
>>>> Do we update the microcode now or do we wait until the latest
>>>> microcode_ctl rpm is available and then tackle this issue?
>>> Check with your hardware vendor for BIOS/EFI firmware updates.
Apply
>>> those.
>>>
>> Thanks for the reply, but you missed what I was asking.? I've
>> already downloaded the appropriate files from the links that Johnny
>> provided in a previous posting.
>> My question is, do we wait until the latest microcode_ctl rpm is
>> installed or do it now?? My concern is that if I do it now the new
>> rpm might undo what I've done.
> 
> It does not matter. The microcode_ctl package contains CPU firmware
> that is loaded at by the kernel early in the boot process if it's newer
> than the one provided by the system firmware/BIOS. It is never
> permanently stored in NVRAM or anything ? it's loaded at each boot.
> 
> You should get a BIOS/EFI firmware update from your hardware vendor
> which includes updated microcode. Then, you'll get the IBRS-capable
> microcode at boot, every boot. This makes microcode_ctl moot.
> 
> Read more about this here: https://access.redhat.com/solutions/3315431
> 
  Thanks, Johnny, Matthew, Peter, ... everybody for your insights!

  Valeri

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