SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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
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.
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
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...
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."
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.
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.
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.
Last edited by bamunds; 03-19-2018 at 04:50 PM.
Reason: correct cat statement to unique output name.
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.
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
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:
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:
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 ... ???
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.