SCIENTIFIC-LINUX-USERS Archives

January 2018

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Reply To:
Date:
Wed, 17 Jan 2018 11:31:47 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (76 lines)
On Wed, 17 Jan 2018, Steve Gaarder wrote:

> Can someone shed some more light on the stability issues that this update 
> addresses?  Is there a way to tell if a machine is having these problems? I 
> had just updated my servers and would rather not have to do it again so soon.

It is going to be a mess for some time.  Red Hat has punted the ball
back to your server vendor and the CPU vendor to provide working CPU firmware
updates.  It is not Red Hat that produces them - they only repackage
the firmware from the CPU vendors in a convenient form to be applied
to CPUs on boot.

Some of these updates have caused big problems on some CPU models; see
https://bugzilla.redhat.com/show_bug.cgi?id=1532283 for example.

Red Hat's microcode update now goes back to last year's version, which
means that any useful microcode security updates for Skylake-, Broadwell-,
and Haswell-based will also disappear when you revert the
microcode_ctl/linux-firmware packages.

So system administrators will need to decide how to manage this
issue until it becomes 'stable' again.

I tried the 20180108 version from Intel on a few older CPUs in our
data centre, but at least for us this update provides no new protection
(but at least now obvious instabilities).

See:
   https://downloadcenter.intel.com/product/873/Processors

I've decided to block updates of this package in the meanwhile to keep
our 'status-quo', and will test firmware updates as they appear on
select CPU models on our servers which are public-facing.

I suppose in time that Red Hat will be able to package a newer 
set of firmware updates from Intel, but they need to be validated
first.  It looks like Intel has not done enough testing...

So each system admin will need to decide how to handle this. 
Probably contacting vendors for your supported systems will move the 
pressure to Intel where it belongs.

cheers, etc.
   denice

> On Wed, 17 Jan 2018, Pat Riehecky wrote:
>
>>   Synopsis:          Important: microcode_ctl security update
>>   Advisory ID:       SLSA-2018:0093-1
>>   Issue Date:        2018-01-16
>>   CVE Numbers:       CVE-2017-5715
>>   --
>>
>>   This update supersedes the previous microcode update provided with the
>>   CVE-2017-5715 (Spectre) CPU branch injection vulnerability mitigation.
>>   Further testing has uncovered problems with the microcode provided along
>>   with the Spectre mitigation that could lead to system instabilities.
>>
>>   As a result, this microcode update reverts to the last known good
>>   microcode version dated before 03 January 2018.
>>
>>   You should contact your hardware provider for the latest microcode
>>   updates.
>>
>>   IMPORTANT: If you are using Intel Skylake-, Broadwell-, and Haswell-based
>>   platforms, obtain and install updated microcode from your hardware
>>   vendor immediately. The "Spectre" mitigation requires both an updated
>>   kernel and updated microcode from your hardware vendor.
...

-- 
deatrich @ triumf.ca, Science/ATLAS         PH: +1 604-222-7665
<*> This moment's fortune cookie:
There's small choice in rotten apples.
 		-- William Shakespeare, "The Taming of the Shrew"

ATOM RSS1 RSS2