[SOLVED] How to load new Intel microcode

kjhambrick · 03-15-2018, 10:33 AM

bamunds --

I updated the intel-microcode SBo Package on four Boxes yesterday:

1. rebuilt and upgradepkg'd intel-microcode
2. rebuilt my initrd files
3. reran lilo
4. rebooted

Two-of-four CPUs got a new microcode file:

This is 'bupbox' running Slackware64 14.2:

Code:

# uname -a

Linux bupbox 4.4.118 #1 SMP Sun Feb 25 14:18:45 CST 2018 x86_64 Intel(R) Core(TM) i3-4150 CPU @ 3.50GHz GenuineIntel GNU/Linux

# dmesg -t |grep -i microcode

microcode: CPU0 microcode updated early to revision 0x24, date = 2018-01-21
microcode: CPU1 microcode updated early to revision 0x24, date = 2018-01-21
microcode: CPU0 sig=0x306c3, pf=0x2, revision=0x24
microcode: CPU1 sig=0x306c3, pf=0x2, revision=0x24
microcode: CPU2 sig=0x306c3, pf=0x2, revision=0x24
microcode: CPU3 sig=0x306c3, pf=0x2, revision=0x24
microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

This is 'sam' running Slackware64-current:

Code:

# uname -a 

Linux samsung.kjh.home 4.14.26 #2 SMP Sun Mar 11 16:19:08 CDT 2018 x86_64 Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz GenuineIntel GNU/Linux

# dmesg -t |grep microcode

microcode: microcode updated early to revision 0x1f, date = 2018-02-07
microcode: sig=0x306a9, pf=0x10, revision=0x1f
microcode: Microcode Update Driver: v2.2.

My Skylake ( i7 6700k ) is still running the 2017-11-16 version

The Zotac ZBox BI325 ( Celeron N3160 ) does not show date for the microcode file, but the revision was the same before and after the intel-microcode update.

Code:

# uname -a

Linux bi3252 4.4.118 #1 SMP Sun Feb 25 14:18:45 CST 2018 x86_64 Intel(R) Celeron(R) CPU  N3160  @ 1.60GHz GenuineIntel GNU/Linux

# dmesg -t |grep microcode

microcode: CPU0 sig=0x406c4, pf=0x1, revision=0x403
microcode: CPU1 sig=0x406c4, pf=0x1, revision=0x403
microcode: CPU2 sig=0x406c4, pf=0x1, revision=0x403
microcode: CPU3 sig=0x406c4, pf=0x1, revision=0x403
microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

HTH and Good Luck with your CPU !

-- kjh

Skaendo · 03-15-2018, 10:52 AM

My guess is that everything skylake and before is "on their own". At least as of now, and probably will be that way in future updates. There may be some backporting to skylake and *maybe* some earlier in the future, but I wouldn't hold my breath.

kjhambrick · 03-15-2018, 11:03 AM

Quote:

Originally Posted by Skaendo

My guess is that everything skylake and before is "on their own". At least as of now, and probably will be that way in future updates. There may be some backporting to skylake and *maybe* some earlier in the future, but I wouldn't hold my breath.

Skaendo --

Skylake does seem to be a problem-CPU but there were definitely updates in the Intel 2018-03-12 file for some older CPUs.

I checked the Microcode Revisions before and after installing 2018-03-12:

Third Gen i5-3210M :

Code:

# head -1 microcode-B80314-before && head -1 microcode-B80314-after

microcode: microcode updated early to revision 0x1c, date = 2015-02-26
microcode: microcode updated early to revision 0x1f, date = 2018-02-07

And Fourth Gen i3-4150 :

Code:

# head -1 microcode-B80314-before && head -1 microcode-B80314-after

microcode: CPU0 microcode updated early to revision 0x22, date = 2017-01-27
microcode: CPU0 microcode updated early to revision 0x24, date = 2018-01-21

HTH

-- kjh

Petri Kaukasoina · 03-15-2018, 11:08 AM

Quote:

Originally Posted by Skaendo

My guess is that everything skylake and before is "on their own".

i5-2400, Sandy Bridge from 2011 got a new microcode. On Linux 4.15.10:

Code:

$ cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
Mitigation: Full generic retpoline, IBPB, IBRS_FW

mralk3 · 03-15-2018, 11:12 AM

Quote:

Originally Posted by Daedra

If I am reading the specter-meltdown-checker correctly it looks like I am not-vulnerable across the board?

Yeah, at least according to that script. I am no expert on the topic. I assume the people working on that script know a lot more about it all than I do, which is why I trust it to be accurate.

I updated my microcode to version 20180312.

Code:

$ uname -pr
4.14.26 Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz

Before:

Code:

[    0.000000] microcode: microcode updated early to revision 0x22, date = 2017-01-27
[    3.777110] microcode: sig=0x306c3, pf=0x10, revision=0x22
[    3.777551] microcode: Microcode Update Driver: v2.2.

After:

Code:

[    0.000000] microcode: microcode updated early to revision 0x24, date = 2018-01-21
[    3.775327] microcode: sig=0x306c3, pf=0x10, revision=0x24
[    3.775722] microcode: Microcode Update Driver: v2.2.

The rest of my systems in the house are varying versions of the Raspberry Pi, which was announced as not vulnerable to any of this. Now to look at the one family Windows 8.1 machine...

Skaendo · 03-15-2018, 11:22 AM

Quote:

Originally Posted by kjhambrick

Skaendo --

Skylake does seem to be a problem-CPU but there were definitely updates in the Intel 2018-03-12 file for some older CPUs.

From what I've heard, every Intel CPU from at least the last 2 decades is affected.

I would bet that they are cherry picking which ones get updates by many factors like how easy the fix is for a model, market share, etc. But I do not know *for sure*. So take it with a grain of salt.

I wouldn't doubt that skylake is getting updates, and earlier models are as well, but if you think that every processor that Intel has made is going to get a microcode update, don't hold your breath.

They may very well update the microcode for every single processor that they've ever made (I doubt it), but thinking that the current release has a update for every/any specific model is not wise. It is best to check like you have because not every model gets updated with every release.

"A false sense of security is worse than no security at all."

55020 · 03-15-2018, 11:26 AM

Quote:

Originally Posted by Skaendo

My guess is that everything skylake and before is "on their own". At least as of now, and probably will be that way in future updates. There may be some backporting to skylake and *maybe* some earlier in the future, but I wouldn't hold my breath.

There's no need to guess.
https://newsroom.intel.com/wp-conten...e-guidance.pdf (March 6 2018)
I think the oldest update currently planned is possibly 'Penryn/QC'.

Skaendo · 03-15-2018, 11:33 AM

Quote:

Originally Posted by 55020

I think the oldest update currently planned is possibly 'Penryn/QC'.

YAY! That means my X9000 might get a update!

@55020
Thanks for that link.

bamunds · 03-15-2018, 12:29 PM

After updating intel-microcode scripts and building the latest /lib/firmware/intel-microcode/

Code:

# iucode_tool -S -l /lib/firmware/intel-ucode/0f-04-07 
iucode_tool: system has processor(s) with signature 0x00000f47
microcode bundle 1: /lib/firmware/intel-ucode/0f-04-07
selected microcodes:
  001/001: sig 0x00000f47, pf_mask 0x9d, 2005-04-21, rev 0x0003, size 3072

shows that my particular CPU and actually all the Smithfield CPU's are still not getting any updates.
Glad the spectre/meltdown is already being addressed by the Linux Kernel dev's.

Here is my latest process decisions for How-To Update Intel Microcode
The following requires that both intel_tools and intel-microcode are already loaded.
So the method I'm adopting gong forward is to each month during my security updates will be to follow:
1. download latest Intel.com microcode for Linux to my downloads folder.
2. locally re-build the /lib/firmware using intel-microcode.SlackBuild (correctly modified for latest download file name)
3. check the /lib/firmware/intel-ucode/ directory with the above command and see if my CPU is updated.
4. if updated then there are two possible paths.
4a In combination with kernel update: download latest kernel and use the flag parameter suggestions from BratPit
in post #15 when running "make menuconfig" to simply get the update for my CPU only added during the bzImage build time.
4b Not in combination with a kernel udpate: simply use the following command to write a new intel-ucode.cpio
for only my CPU.

Code:

iucode_tool --write-earlyfw=intel-ucode.cpio /tmp/microcode-20180108/intel-ucode/0f-04-07

This will also keep my system from getting a large /intel-ucode.cpio file in /boot.
5. Next follow the steps for
a) Building a Kernel from Source or
b) the steps for concatenated as stated in post #94
cat intel-ucode.cpio initrd_4.14.13-smp.gz > initrd_4.14.13_ucode-smp.gz
and don't forget to fix both the lilo.conf stanza's and rerun lilo before a reboot.

PS. 4.4.121 has a x86/spectre and also a ipv4 fix which I think are important and some may want to consider.

Cheers.

Loomx · 03-15-2018, 12:58 PM

Quote:

cat intel-ucode.cpio initrd_4.14.13-smp.gz > initrd_4.14.13-smp.gz

If you run this command, the '>' will first truncate the initrd_4.14.13-smp.gz file to zero length, then do the `cat'.
You need to give the output file a different name.

See https://mywiki.wooledge.org/BashGuide/InputAndOutput

(You could then rename the new initrd back to the original name as a separate step)

bamunds · 03-15-2018, 01:50 PM

@loomx, thanks I was too fast to paste and cut from the post. Yes the output name must be unique from the input name, I've corrected the post. Cheers,

teoberi · 03-16-2018, 04:35 AM

If I run Spectre and Meltdown mitigation detection tool v0.35 I get:

Quote:

Hardware check
* Hardware support (CPU microcode) for mitigation techniques
* Indirect Branch Restricted Speculation (IBRS)
* SPEC_CTRL MSR is available: YES
* CPU indicates IBRS capability: YES (SPEC_CTRL feature bit)
* Indirect Branch Prediction Barrier (IBPB)
* PRED_CMD MSR is available: YES
* CPU indicates IBPB capability: YES (SPEC_CTRL feature bit)
* Single Thread Indirect Branch Predictors (STIBP)
* SPEC_CTRL MSR is available: YES
* CPU indicates STIBP capability: YES
...
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Mitigation 1
* Kernel is compiled with IBRS/IBPB support: NO
* Currently enabled features
* IBRS enabled for Kernel space: NO
* IBRS enabled for User space: NO
* IBPB enabled: NO

This means that the Slackware kernel is not compiled with support for IBRS/IBPB?
RedHat recommends here
https://access.redhat.com/articles/3311301
these options

Quote:

Intel Defaults:
pti=1 ibrs=0 retp=1 ibpb=1-> fix variant#1 #2 #3 for pre-Skylake cpus
pti=1 ibrs=1 retp=0 ibpb=1-> fix variant#1 #2 #3 for Skylake cpus
pti=1 retp=1 ibrs=0 ibpb=0 -> fix variant#1 #3 (for older Intel systems with no microcode update available)

My question is how can I activate IBRS/IBPB support?

kjhambrick · 03-16-2018, 06:05 AM

teoberi --

What version of Slackware and which Kernel do you run ?

As far as I can tell, the latest Kernel Mitigation Code has not yet been backported to the 4.4.y Kernel ( Slackware 14.2's Official Kernel ).

However, there was an additional mitigation in last night's Slackware-current 4.14.27 Kernel ( note the spectre_v2 lines ).

These were the mitigations listed for the 4.14.26 Kernel ( before last night's update ) on a Laptop with an i5-3210M CPU with the latest intel-microcode:

Code:

# gawk '{ print FILENAME "\t" $0 }' /sys/devices/system/cpu/vulnerabilities/*

/sys/devices/system/cpu/vulnerabilities/meltdown        Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1      Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2      Mitigation: Full generic retpoline, IBPB

And these are the mitigations listed after installing last night's Slackware-current 4.14.27 Kernel:

Code:

# gawk '{ print FILENAME "\t" $0 }' /sys/devices/system/cpu/vulnerabilities/*

/sys/devices/system/cpu/vulnerabilities/meltdown        Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1      Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2      Mitigation: Full generic retpoline, IBPB, IBRS_FW

For comparison, these are the mitigations listed for the 4.4.118 kernel from a 'stock' Slackware64 14.2 box with a i3-4150 CPU on the latest intel-microcode:

Code:

# gawk '{ print FILENAME "\t" $0 }' /sys/devices/system/cpu/vulnerabilities/*

/sys/devices/system/cpu/vulnerabilities/meltdown        Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1      Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2      Mitigation: Full generic retpoline

There are a lot of interesting entries in the 4.14.27 ChangeLog: https://cdn.kernel.org/pub/linux/ker...ngeLog-4.14.27 (

not that I pretend to understand them all

)

HTH

-- kjh

EDIT:

P.S. If I recall, RedHat is running a patched 3.10 Kernel so there may be additional steps to apply the mitigations on a RHEL 7 System ?

I don't believe you need to do anything for the latest mitigations to be applied to the 4.4.y Kernels in Slackware 14.2 or the 4.14.y Kernels in Slackware-current.

And ... if previous Kernel Release History is any indicator, there may be additional mitigation code back-ported to 4.4.122 which would be released after a couple rc's ... say, later this weekend or early next week ... ???

If you're interested in the process, you can watch Greg KH's work in progress here: https://git.kernel.org/pub/scm/linux...stable-rc.git/

teoberi · 03-16-2018, 06:25 AM

Slackware64-current with kernel 4.14.27
gawk '{ print FILENAME "\t" $0 }' /sys/devices/system/cpu/vulnerabilities/*

Quote:

/sys/devices/system/cpu/vulnerabilities/meltdown Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1 Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2 Mitigation: Full generic retpoline, IBPB, IBRS_FW

I checked on a server without updating the microcode:

Quote:

/sys/devices/system/cpu/vulnerabilities/meltdown Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1 Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2 Mitigation: Full generic retpoline

Maybe the script "spectre-meltdown-checker.sh" needs to be updated!

abga · 03-16-2018, 06:49 AM

https://lwn.net/Articles/743019/