similar to: /lib/firmware/microcode.dat update on CentOS 6

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

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

On Thu, Jan 18, 2018 at 5:03 AM, Johnny Hughes <johnny at centos.org> wrote: > On 01/18/2018 03:41 AM, 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

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

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

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

On 01/18/2018 03:41 AM, 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

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

On 01/18/2018 07:51 AM, Phelps, Matthew wrote: > On Thu, Jan 18, 2018 at 5:03 AM, Johnny Hughes <johnny at centos.org> wrote: > >> On 01/18/2018 03:41 AM, Pete Biggs wrote: >>> >>>> Look at: >>>> >>>> https://t.co/6fT61xgtGH >>>> >>>> Get the latest microcode.dat file from here: >>>>

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]

Once upon a time, Chris Murphy <lists at colorremedies.com> said: > "We recommend that OEMs, cloud service providers, system > manufacturers, software vendors and end users stop deployment of > current versions." Current versions of what? Microcode? Well, that's the only thing Intel provides for CPUs, so that's all it can be. > What these means for people who

On 01/18/18 09:01, Johnny Hughes wrote: > On 01/18/2018 07:51 AM, Phelps, Matthew wrote: >> On Thu, Jan 18, 2018 at 5:03 AM, Johnny Hughes <johnny at centos.org> wrote: >> >> So, if we applied the previous microcode update, and all our machines >> rebooted OK, then we don't need to fallback? >> >> Also, do we know if the updated CentOS microcode RPM

On Wed, Jan 24, 2018 at 4:41 PM, Leon Fauster <leonfauster at googlemail.com> wrote: ... > > Comparing microcode-20171117 with microcode-20180108 shows that > from the 94 ucode files only 19 where updated > > $ diff -r --brief microcode-20171117 microcode-20180108 > Files microcode-20171117/intel-ucode/06-3c-03 and microcode-20180108/intel-ucode/06-3c-03 differ > Files

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

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

> Am 24.01.2018 um 22:22 schrieb Chris Adams <linux at cmadams.net>: > > Once upon a time, Chris Murphy <lists at colorremedies.com> said: >> "We recommend that OEMs, cloud service providers, system >> manufacturers, software vendors and end users stop deployment of >> current versions." Current versions of what? Microcode? > > Well,

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

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. -- Matthew Miller <mattdm at fedoraproject.org> Fedora Project Leader

Hi all! I'm running an up-to-date Centos-7 on an AMD Vishera 6300, 6 core CPU. I note that when I run the redhat script to test for spectre & meltdown I get this result for variant 2: Variant #2 (Spectre): Vulnerable CVE-2017-5715 - speculative execution branch target injection - Kernel with mitigation patches: OK - HW support / updated microcode: NO - IBRS: Not disabled on

By now, we're sure most everyone have heard of the Meltdown and Spectre attacks. If not, head over to https://meltdownattack.com/ and get an overview. Additional technical details are available from Google Project Zero. https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html The FreeBSD Security Team was notified of the issue in late December and received a