[SOLVED] How to set up early load of Intel firmware
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 just ran the same script on my LFS 8.2 system which now runs linux-4.19.43. With this kernel, all the vulnerabilities are patched except Rogue system register read, which needs later firmware than I can get hold of. Perhaps I should run my Slackware with this kernel.
I suppose there's no harm in giving it a go as long as you retain at least one working version of an older kernel. However, does it really matter that much? Pat has not released a 4.4.180 which, rather than being tardiness on his part, is probably more by intention, at least to an extent.
I am still running 4.4.153 on my main 14.2 machine. The script does say:
"a false sense of security is worse than no security at all".
So maybe better to just wait.
Last edited by Lysander666; 05-22-2019 at 03:47 AM.
I'm running a fully patched SW 14.2 using kernel 4.4.180 x86_64 from DUSK (https://blog.idlemoor.tk/2016/12/17/dusk.html)
plus an initrd that incorporates the intel-microcode-20190514a-noarch-1_SBo generated /boot/intel-ucode.cpio
My CPU is Dual Core Intel Core i5-2540M.
# spectre-meltdown-checker.sh --batch
CVE-2017-5753: OK (Mitigation: __user pointer sanitization)
CVE-2017-5715: OK (Full retpoline + IBPB are mitigating the vulnerability)
CVE-2017-5754: OK (Mitigation: PTI)
CVE-2018-3640: OK (your CPU microcode mitigates the vulnerability)
CVE-2018-3639: OK (Mitigation: Speculative Store Bypass disabled via prctl and seccomp)
CVE-2018-3615: OK (your CPU vendor reported your CPU model as not vulnerable)
CVE-2018-3620: OK (Mitigation: PTE Inversion)
CVE-2018-3646: OK (this system is not running a hypervisor)
CVE-2018-12126: OK (Mitigation: Clear CPU buffers; SMT vulnerable)
CVE-2018-12130: OK (Mitigation: Clear CPU buffers; SMT vulnerable)
CVE-2018-12127: OK (Mitigation: Clear CPU buffers; SMT vulnerable)
CVE-2019-11091: OK (Mitigation: Clear CPU buffers; SMT vulnerable)
I'm not ready to run my daily driver on -current yet, and feel using a 4.4 kernel there is better than trying to pry a 4.19 kernel to a 14.2 base
Just wanted to report that between SBo and DUSK (much thanks to both !!) that a fairly simple, effective patching is possible
So how do I enable it? That Red Hat article assumes more knowledge than I have! Do I need to add ibpb=1 to my command line?
AFAIK, there is(was) ongoing improvement in the kernel mitigation for theses CPU vulnerabilities, more automation and the more in-depth kernel documentation looks unavailable. You could learn more form the kernel mailing list and the patch descriptions...
ibpb=1 is documented by RedHat, but it's also dependent on the CPU type, microcode update and supposedly also on the kernel version (mitigation level/patch). https://access.redhat.com/articles/3...al-defaults-11
Thanks for all the links but this is way above my intellectual level. I think I will just use the LFS kernel (or, if I have time, a rebuild of the same kernel version from source with the Slackware configuration) and be thankful that the main vulnerabilities are patched. No doubt we shall soon get a compiled Slackware kernel that rings all the bells.
Thanks for all the links but this is way above my intellectual level. I think I will just use the LFS kernel (or, if I have time, a rebuild of the same kernel version from source with the Slackware configuration) and be thankful that the main vulnerabilities are patched. No doubt we shall soon get a compiled Slackware kernel that rings all the bells.
In #9 you stated that you were running the 4.4.172 kernel and then in #13 you presented a snippet from the Spectre and Meltdown mitigation detection tool:
Quote:
CVE-2017-5753 Spectre 1: Mitigated, not vulnerable CVE-2017-7515 Spectre 2: Mitigated, not vulnerable but should enable IBBP
CVE-2017-5754 Meltdown: Mitigated, not vulnerable
CVE-2018-3640 Variant 3A: Vulnerable. More up-to-date firmware required.
CVE-2018-12126 Fallout: Vulnerable. Microcode supports mitigation but kernel does not.
CVE-2018-12130 Zombieload: Vulnerable. Microcode supports mitigation but kernel does not.
CVE-2018-12127 RIDL: Vulnerable. Microcode supports mitigation but kernel does not.
CVE-2019-11091 RIDL: Vulnerable. Microcode supports mitigation but kernel does not.
In my case, a Haswell Core i3, latest microcode, running the latest Slackware 64 - 14.2 kernel 4.4.172, related to the Spectre 2 & IBPB & Spectre 3a (rogue system register read), I have the following:
Code:
Spectre and Meltdown mitigation detection tool v0.40
Checking for vulnerabilities on current system
Kernel is Linux 4.4.172 #2 SMP Wed Jan 30 17:11:07 CST 2019 x86_64
....
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 (Intel STIBP feature bit)
* Speculative Store Bypass Disable (SSBD)
* CPU indicates SSBD capability: YES (Intel SSBD)
....
* CPU microcode is known to cause stability problems: NO (model 0x45 family 0x6 stepping 0x1 ucode 0x25 cpuid 0x40651)
* CPU microcode is the latest known available version: YES (latest version is 0x25 dated 2019/02/26 according to builtin MCExtractor DB v110 - 2019/05/11)
...
* Vulnerable to CVE-2018-3640 (Variant 3a, rogue system register read): YES
...
CVE-2017-5715 aka 'Spectre Variant 2, branch target injection'
* Mitigated according to the /sys interface: YES (Mitigation: Full generic retpoline, IBPB, IBRS_FW)
* Mitigation 1
* Kernel is compiled with IBRS support: YES
* IBRS enabled and active: YES (for firmware code only)
* Kernel is compiled with IBPB support: YES
* IBPB enabled and active: YES
* Mitigation 2
* Kernel has branch predictor hardening (arm): NO
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
> STATUS: NOT VULNERABLE (Full retpoline + IBPB are mitigating the vulnerability)
...
CVE-2018-3640 aka 'Variant 3a, rogue system register read'
* CPU microcode mitigates the vulnerability: YES
> STATUS: NOT VULNERABLE (your CPU microcode mitigates the vulnerability)
Which shows that the latest 4.4.172 kernel Slackware 14.2 is providing "rings all the bells". All the bells except the latest MDS vulnerabilities.
Your CPU might not support IBPB ... you need to check that: https://software.intel.com/security-...dictor-barrier
Quote:
A processor supports IBPB if it enumerates CPUID.(EAX=7H,ECX=0):EDX[26] as 1.
- easier - Spectre and Meltdown mitigation detection tool should check&report that
Speaking of patch level, by only looking(comparing) at the kernel-parameters.txt, found in the kernel source archive, noticed that the 4.4.172 doesn't have:
Code:
spectre_v2_user=
[X86] Control mitigation of Spectre variant 2
(indirect branch speculation) vulnerability between
user space tasks
Option that is present in both 4.4.180 (not yet available for Slackware 14.2) and 4.19.44 (latest for Slackware -current).
Last edited by abga; 05-22-2019 at 12:19 PM.
Reason: typo
You shouldn't, a great part of the English language (German too, but at least there are native (official) alternatives for many Latin words) is comprised of anglicized Latin words...
Besides, in German, there's a deliberate use of Latin originated words by (what I call) 2 digit IQ people just to sound "posh".
- end of off-topic
You shouldn't, a great part of the English language (German too, but at least there are native (official) alternatives for many Latin words) is comprised of anglicized Latin words...
Besides, in German, there's a deliberate use of Latin originated words by (what I call) 2 digit IQ people just to sound "posh".
- end of off-topic
Absolutely understood and acknowledged, I just couldn't get my head around it. Greek, I preferred. But to know the etymological root of certain words is of great benefit, I feel.
So I built the 4.19.43 kernel that I use in LFS using the Slackware config file from /boot. I got a few warnings about things being configured as modules that can't be modules in that kernel version. But that problem seems to have been self-correcting because it built without problems except that it took forever (all those modules!). I just booted it and ran that test script and everything is now cleared except CVE-2018-3640 aka 'Variant 3a, rogue system register read', which needs more up-to-date firmware.
It's not an orthodox solution, but I don't want to go to -current, so it will have to do until the next release comes out.
Since I'm totally new to that stuff, could you confirm that for my cpu wich is
Code:
Famille de processeur*: 6
Modèle*: 69
Nom de modèle*: Intel(R) Core(TM) i7-4510U CPU @ 2.00GHz
Révision*: 1
I would find the cpio microcode file with number 06-45-1 here ?
(assuming that 69 in hex is 45)
If this is right, I could download it somwhere and rename it to date_of_release.cpio and rebuilt my initrd with additional -P flag. Still right ?
(might look for the good option to add in mkinitrd.conf)
Thanks in advance for your lights !
Last edited by Tonus; 06-05-2019 at 03:08 PM.
Reason: try to fix bad english
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.