Opened 3 years ago

Closed 3 years ago

#10844 closed enhancement (fixed)

newer intel microcode

Reported by: ken@… Owned by: ken@…
Priority: normal Milestone: 8.3
Component: BOOK Version: SVN
Severity: normal Keywords:
Cc:

Description

The latest version at intel is 20180425.

As well as intel-ucode/ the tarball contains a linux-patches/ directory, with a note that these patches are to quiesce all logical CPUs during a live update after the system is booted, and that they are all upstream in latest supported 4.14 or later kernels (but not 4.9 or 4.4 at that date).

My haswell got a new update, to 0x24, which I assumed was to fix spec_store_bypass. But after booting with early update my machine is still marked as 'vulnerable'. I found the documentation on how to set the kernel parameter ambiguous (too many negatives), so I have tried booting both with forcing 'on' and with forcing 'off', as well as the default of not specifying. But in each case, 'vulnerable'.

I assume that if the vulnerability is fixed, the machine will be slower (hence the other values for the boot param). So I wanted to test that, but apparently I can't.

Perhaps I should mention that my machine's newer firmware is dated in January.

Maybe I'm doing something wrong, but I'm not willing to touch this issue until I understand it.

Change History (3)

comment:1 by ken@…, 3 years ago

On my ryzen, the default for spec_store_bypass is

Mitigation: Speculative Store Bypass disabled via prctl and seccomp

which actually means "only enabled if you force it for a process, or if a process uses seccomp".

Adding a boot arg of spec_store_bypass_disable=on (and rebooting!) gives:

Mitigation: Speculative Store Bypass disabled

which I now thing is the way to force it off. For the moemnt, no time to test the impact, and since on my haswell the new firmware is apparently not enough to do this I'll still leave the ticket.

comment:2 by ken@…, 3 years ago

Owner: changed from blfs-book to ken@…
Status: newassigned

It turns out that I managed to use an OLD initrd for my latest build on the haswell, still need to understand how that happened. After not finding any newer ucode for a different machine, I took a closer look. As well as the ucode directory and the kernel patches, there is also a top-level releasenote. [ I hate tarballs that scatter things in the current directory! ].

Diffing that says:

Updated platforms 6-7a-1 some Pentium Silver N/J5xxx, Celeron N/J4xxx 6-4f-1 Xeon E5/E7 v4, Core i7-69xx/68xx removed, replaced by special release with caveats.

Comparing the md5sums of all the blobs shows 2 changes, 06-4f-01 (removed), 06-7a-01 (changed).

So, the Xeon E5/E7 and i7-88xx/69xx (Broadwell E) microcode has been deleted, and microcode for Gemini Lake Pentium/Celeron has been added.

This version does NOT address any more recent vulnerabilities.

I'll fix the book (and add a mention of AMD Fam17h, if I remember) after I've worked out what happened on my haswell.

comment:3 by ken@…, 3 years ago

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.