Updated to the latest Intel microcode, but still vulnerable to one variant.

john2x · 08-07-2018, 03:16 AM

Hi, I'm running Slackware 14.2. I've upgraded my kernel to 4.4.144, updated the SBo package for `intel-ucode` to the latest version, regenerated my initrd with MICROCODE_ARCH="/boot/intel-ucode.cpio", and updated my ELILO conf. But it seems I am still vulnerable to `spec_store_bypass`? What am I missing?

Here are some details:

Code:

    root@slack:~# dmesg | grep microcode
    [    4.477893] microcode: CPU0 sig=0x306a9, pf=0x10, revision=0x1f
    [    4.478714] microcode: CPU1 sig=0x306a9, pf=0x10, revision=0x1f
    [    4.479518] microcode: CPU2 sig=0x306a9, pf=0x10, revision=0x1f
    [    4.480297] microcode: CPU3 sig=0x306a9, pf=0x10, revision=0x1f
    [    4.481401] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
    root@slack:~# cat /sys/devices/system/cpu/vulnerabilities/meltdown
    Mitigation: PTI
    root@slack:~# cat /sys/devices/system/cpu/vulnerabilities/spectre_v1
    Mitigation: __user pointer sanitization
    root@slack:~# cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
    Mitigation: Full generic retpoline, IBPB, IBRS_FW
    root@slack:~# cat /sys/devices/system/cpu/vulnerabilities/spec_store_bypass
    Vulnerable
    root@slack:~# uname -a
    Linux slack 4.4.144 #1 SMP Thu Jul 26 12:26:39 CDT 2018 x86_64 Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz GenuineIntel GNU/Linux

teoberi · 08-07-2018, 03:25 AM

An upgraded BIOS / CPU microcode when it will be available.

abga · 08-07-2018, 05:44 AM

Quote:

Originally Posted by john2x

Hi, I'm running Slackware 14.2. I've upgraded my kernel to 4.4.144, updated the SBo package for `intel-ucode` to the latest version, regenerated my initrd with MICROCODE_ARCH="/boot/intel-ucode.cpio", and updated my ELILO conf. But it seems I am still vulnerable to `spec_store_bypass`? What am I missing?

Try passing the spec_store_bypass_disable=on or auto boot parameter:
https://www.suse.com/support/kb/doc/?id=7022937

Additionally, your CPU microcode doesn't look updated. According to (page 10):
https://www.intel.com/content/dam/ww...e-guidance.pdf
Your CPU (IvyBridge Core(TM) i5-3210M) microcode revision should be on:
revision=0x20 and not on revision=0x1f
Try applying this patch for the latest microcode update package from Intel ( Version: 20180703 (Latest) Date: 7/3/2018 ):
https://www.linuxquestions.org/quest...4/#post5879706
Even if the latest microcode revision is 0x20 in Intel's Microcode Update Guide, there's still a chance it didn't make it in the published microcode package, but only distributed to the OEM partners.

ponce · 08-07-2018, 06:27 AM

Quote:

Originally Posted by abga

Try applying this patch for the latest microcode update package from Intel ( Version: 20180703 (Latest) Date: 7/3/2018 ):
https://www.linuxquestions.org/quest...4/#post5879706

in the meantime Andrzej updated also the script on SBo

https://slackbuilds.org/repository/1...tel-microcode/

The_Dark_Passenger · 08-07-2018, 11:35 AM

I'm also in the same boat with my laptop. I updated the microcode on my workstation and laptop today; my workstation has a Xeon E5-1650v2, and my laptop has a Core i5 4250U. I updated my workstation using the Slackbuild and rebuilt my initrd, rebooted and it updates the microcode correctly. On my laptop now, I perform the same steps to update it as I did my workstation, however the microcode never updates beyond 0x23, where Intel lists it should be on 24 now. I checked the dmesg, and on my laptop it never lists anything about the microcode updating as it does on my workstation.

I did notice in the releasenotes for the microcode, it only lists a few processor families, and nothing about Haswell. Is this the reason why my laptop isn't using 0x24. Also, if that's the case, is it normal for it to not be listing that it's using an updated microcode in dmesg, or should it still be saying something?

abga · 08-07-2018, 12:05 PM

Quote:

Originally Posted by The_Dark_Passenger

I did notice in the releasenotes for the microcode, it only lists a few processor families, and nothing about Haswell. Is this the reason why my laptop isn't using 0x24. Also, if that's the case, is it normal for it to not be listing that it's using an updated microcode in dmesg, or should it still be saying something?

I own a DELL i3 Haswell ULT laptop and yesterday DELL releasde a new BIOS for it, flashed it and now I finally have the microcode 0x24 on it.
https://www.intel.com/content/dam/ww...e-guidance.pdf
Page 9 Haswell U - New Production MCU Rev 0x24
By using the latest Intel microcode package - Version: 20180703 (Latest) Date: 7/3/2018 I was still on 0x23:
kernel: [ 3.679031] microcode: CPU0 sig=0x40651, pf=0x40, revision=0x23
kernel: [ 3.679173] microcode: CPU1 sig=0x40651, pf=0x40, revision=0x23

Intel is sending the latest microcode updates to its OEM partners first and only after that releasing the updated downloadable package.
That microcode guide they're publishing is good for orientation/expectation only, the release notes that come with the microcode downloadable package are the ones that actually matter.

ponce · 08-08-2018, 03:15 AM

another release of intel's microcode is out: a simple version-bump of the SlackBuild is enough to package it

https://downloadcenter.intel.com/download/28039?v=t

stormtracknole · 08-08-2018, 09:10 AM

Quote:

Originally Posted by abga

Try passing the spec_store_bypass_disable=on or auto boot parameter:
https://www.suse.com/support/kb/doc/?id=7022937

Additionally, your CPU microcode doesn't look updated. According to (page 10):
https://www.intel.com/content/dam/ww...e-guidance.pdf
Your CPU (IvyBridge Core(TM) i5-3210M) microcode revision should be on:
revision=0x20 and not on revision=0x1f
Try applying this patch for the latest microcode update package from Intel ( Version: 20180703 (Latest) Date: 7/3/2018 ):
https://www.linuxquestions.org/quest...4/#post5879706
Even if the latest microcode revision is 0x20 in Intel's Microcode Update Guide, there's still a chance it didn't make it in the published microcode package, but only distributed to the OEM partners.

Adding:

Code:

spec_store_bypass_disable=on

was what I was missing. Adding this to Grub (and I'm sure LILO) finally made the spectre script happy for the last variant. My machines are now NOT vulnerable for any of the vulnerabilities.

kjhambrick · 08-08-2018, 02:08 PM

Thanks All'Y'All !

I installed 20180807 and I see first the microcode update for my i7 6700K Processor since last November (( Family-Model-Stepping )=( 06-5e-03 ))

Code:

# uname -a

Linux kjhlt6 4.4.146.kjh #1 SMP Mon Aug 6 17:10:20 CDT 2018 x86_64 Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz GenuineIntel GNU/Linux                                                                              

# dmesg -t |grep microcode

microcode: CPU0 microcode updated early to revision 0xc6, date = 2018-04-17
microcode: CPU1 microcode updated early to revision 0xc6, date = 2018-04-17
microcode: CPU2 microcode updated early to revision 0xc6, date = 2018-04-17
microcode: CPU3 microcode updated early to revision 0xc6, date = 2018-04-17                             
microcode: CPU0 sig=0x506e3, pf=0x2, revision=0xc6                                                      
microcode: CPU1 sig=0x506e3, pf=0x2, revision=0xc6                                                      
microcode: CPU2 sig=0x506e3, pf=0x2, revision=0xc6                                                      
microcode: CPU3 sig=0x506e3, pf=0x2, revision=0xc6                                                      
microcode: CPU4 sig=0x506e3, pf=0x2, revision=0xc6                                                      
microcode: CPU5 sig=0x506e3, pf=0x2, revision=0xc6                                                      
microcode: CPU6 sig=0x506e3, pf=0x2, revision=0xc6                                                      
microcode: CPU7 sig=0x506e3, pf=0x2, revision=0xc6                                                      
microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

And adding the spec_store_bypass_disable=on kernel parameter to /etc/lilo.conf, I am once again 'mitigated'

Code:

# get-spectre-meltdown.sh

meltdown:            Mitigation =  PTI
spec_store_bypass:   Mitigation =  Speculative Store Bypass disabled
spectre_v1:          Mitigation =  __user pointer sanitization
spectre_v2:          Mitigation =  Full generic retpoline, IBPB, IBRS_FW

Thanks again !!

-- kjh

This is get-spectre-meltdown.sh

Code:

#!/bin/sh

gawk '
BEGIN {

   Fmt = "%-20s %s\n"
}
# main
{
   N = split( FILENAME, A, "/" )   # Array A for a poor-mans basename
   M = $0                          # M is the "mitigation"

   gsub( /:/, " = ", M )

   printf( Fmt, A[N] ":", M )

}' /sys/devices/system/cpu/vulnerabilities/*

abga · 08-08-2018, 03:03 PM

I don't know why I only could find that suse article in the first place and not the more detailed RedHat one:
https://access.redhat.com/security/vulnerabilities/ssbd
- Overview Tab - the technical details
- Resolve Tab - go down the page until you reach the Mitigation section
As I understand it, you'll need both microcode update and kernel patch to fully mitigate CVE-2018-3639 and the more appropriate option should be:
spec_store_bypass_disable=auto

Performance impact analysis of the mitigation, might be of interest:
https://www.phoronix.com/scan.php?pa...tre-ssbd&num=1
(skip to the third page for conclusions)

kjhambrick · 08-08-2018, 04:25 PM

Thanks abga.

Appended spec_store_bypass_disable=auto instead of spec_store_bypass_disable=on to my append= line in lilo.conf ; ran lilo and rebooted.

These are now my mitigations:

Code:

meltdown:            Mitigation =  PTI
spec_store_bypass:   Mitigation =  Speculative Store Bypass disabled via prctl and seccomp
spectre_v1:          Mitigation =  __user pointer sanitization
spectre_v2:          Mitigation =  Full generic retpoline, IBPB, IBRS_FW

I like it !

More words compared to when I set spec_store_bypass_disable=on

-- kjh (

more words is good words

)

twy · 08-08-2018, 05:24 PM

I run a Lynnfield Xeon x3450 released in 2009. The new microcode-20180807 finally has a Lynnfield ucode 0xa update. The previous ucode was 0x7. The SlackBuild for intel-microcode was used (editing the version in the SlackBuild file) without any problem to install microcode-20180807.

For Lynnfield users, it appears that ucode 0xa adds CPU features for "Speculative Execution Side Channel Mitigations":
* SSBD, Speculative Store Bypass Disable
* IBRS, Indirect Branch Restricted Speculation
* IBPB, Indirect Branch Prediction Barrier
* STIBP, Single Thread Indirect Branch Predictors

I run the latest 4.4.146 kernel on slackware64-14.2. As a result, I have all of the current mitigations (cat /sys/devices/system/cpu/vulnerabilities/*):

meltdown: Mitigation: PTI
spec_store_bypass: Mitigation: Speculative Store Bypass disabled via prctl and seccomp
spectre_v1: Mitigation: __user pointer sanitization
spectre_v2: Mitigation: Full generic retpoline, IBPB, IBRS_FW

Looks good. Now, I'll have to see the performance hit, and see if my system is still stable!

Uncle Lumpy · 08-08-2018, 05:50 PM

On my machines, I did not need to append spec_store_bypass_disable=auto to my lilo.conf (nor my elilo.conf). I think "auto" is the default. Once I updated my machines to the latest intel microcode (and the latest kernels), the spec_store_bypass mitigation shows as being "Speculative Store Bypass disabled via prctl and seccomp." No need to append anything in lilo.conf (or elilo.conf).

Best,
Lumpy

mralk3 · 08-08-2018, 10:34 PM

Quote:

Originally Posted by Uncle Lumpy

On my machines, I did not need to append spec_store_bypass_disable=auto to my lilo.conf (nor my elilo.conf). I think "auto" is the default. Once I updated my machines to the latest intel microcode (and the latest kernels), the spec_store_bypass mitigation shows as being "Speculative Store Bypass disabled via prctl and seccomp." No need to append anything in lilo.conf (or elilo.conf).

Best,
Lumpy

I am waiting to see if this is the case on my Fedora machine. Eagerly awaiting the latest microcode update.

kjhambrick · 08-09-2018, 04:24 AM

Thanks Uncle Lumpy.

I removed spec_store_bypass_disable=auto from the append= line in /etc/lilo.conf ; reran lilo and rebooted.

I have the same set of mitigations on Slackware64 14.2 with the 4.4.146 Kernel that I had with the spec_store_bypass_disable=auto setting

Code:

meltdown:            Mitigation: PTI
spec_store_bypass:   Mitigation: Speculative Store Bypass disabled via prctl and seccomp
spectre_v1:          Mitigation: __user pointer sanitization
spectre_v2:          Mitigation: Full generic retpoline, IBPB, IBRS_FW

-- kjh(

less settings is better settings

)

P.S. Now I am curious what I'll see with the latest official Slackware 14.2 Kernel ( Linux 4.4.144 )