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.
/home/dld/spectre-meltdown-checker/spectre-meltdown-checker-0.35/spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.35
Checking for vulnerabilities on current system
Kernel is Linux 4.4.118.kjh #1 SMP Sun Feb 25 05:19:50 CST 2018 x86_64
CPU is Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
Hardware check
* Hardware support (CPU microcode) for mitigation techniques
* Indirect Branch Restricted Speculation (IBRS)
* SPEC_CTRL MSR is available: NO
* CPU indicates IBRS capability: NO
* Indirect Branch Prediction Barrier (IBPB)
* PRED_CMD MSR is available: NO
* CPU indicates IBPB capability: NO
* Single Thread Indirect Branch Predictors (STIBP)
* SPEC_CTRL MSR is available: NO
* CPU indicates STIBP capability: NO
* Enhanced IBRS (IBRS_ALL)
* CPU indicates ARCH_CAPABILITIES MSR availability: NO
* ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
* CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO
* CPU microcode is known to cause stability problems: NO (model 94 stepping 3 ucode 0xba)
* CPU vulnerability to the three speculative execution attacks variants
* Vulnerable to Variant 1: YES
* Vulnerable to Variant 2: YES
* Vulnerable to Variant 3: YES
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Kernel has array_index_mask_nospec: YES (1 occurence(s) found of 64 bits array_index_mask_nospec())
* Kernel has the Red Hat/Ubuntu patch: NO
> STATUS: NOT VULNERABLE (Mitigation: __user pointer sanitization)
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
* Mitigation 2
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
> STATUS: NOT VULNERABLE (Mitigation: Full generic retpoline)
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
* Running as a Xen PV DomU: NO
> STATUS: NOT VULNERABLE (Mitigation: PTI)
A false sense of security is worse than no security at all, see --disclaimer
Last edited by kjhambrick; 02-25-2018 at 05:54 AM.
Reason: does include - now includes
@kjh - just to help the newbie.... Maybe your older post from 2-9-18 should be edited to correctly read 4.14.17 and 4.14.18, Otherwise, I'm totally confused because I thought everything up to 4.4.117 is vulnerable and 4.4.118 is not according to your post yesterday. Any comments?
BTW - I read the release notes and didn't see a CVE fix for Spectre v1, I'm wondering why the kernel dev team wouldn't have noted that CVE fix in the kernel release notes? Maybe I'll upgrade to 4.4.118 tonight and see if I get the same results then report back.
Cheers.
Quote:
Originally Posted by kjhambrick
Today's Slackware64 current 4.14.18 update fixes Spectre v1 on my test box:
Code:
# uname -a
Linux samsung.kjh.home 4.14.18 #1 SMP Thu Feb 8 12:48:42 CST 2018 x86_64 Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz GenuineIntel GNU/Linux
4.4.17 ( updates thru Wed Feb 7 04:28:48 UTC 2018 )
Code:
/sys/devices/system/cpu/vulnerabilities/meltdown: Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1: Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v2: Mitigation: Full generic retpoline
4.4.18 ( includes Fri Feb 9 02:50:56 UTC 2018 updates )
@kjh - just to help the newbie.... Maybe your older post from 2-9-18 should be edited to correctly read 4.14.17 and 4.14.18, Otherwise, I'm totally confused because I thought everything up to 4.4.117 is vulnerable and 4.4.118 is not according to your post yesterday. Any comments?
BTW - I read the release notes and didn't see a CVE fix for Spectre v1, I'm wondering why the kernel dev team wouldn't have noted that CVE fix in the kernel release notes? Maybe I'll upgrade to 4.4.118 tonight and see if I get the same results then report back.
Cheers.
bamunds --
Good Eye ! Thanks for the heads up.
I see the errors that you're referring to in my earlier post ( 4.4.17 instead of 4.14.17 -and- 4.4.18 instead of 4.14.18 )
Yes, I would like to fix those for posterity ...
However, I guess the post is too old because the LQ interface does not offer me an [Edit] button.
Sorry.
As for the CVE References ...
These lines in my LQ New Kernel posts are generated by a script which reads the kernel.org HomePage and then does a simple search thru each ChangeLog for the REx: /[Cc][Vv]Ee]-[0-9][0-9][0-9][0-9]-[0-9]+/
I double-checked the NULL result by opening the 4.4.118 ChangeLog in PaleMoon and searched for 'CVE-' ... PaleMoon didn't find any occurrances either.
I am not sure when-or-why the the Kernel Dev's commit comments do-or-do-not include references to CVEs' but looking back thru a few of the 4.4.y ChangeLogs, I didn't see CVE's for the BackPorted Spectre / Meltdown Code ...
If anyone's interested on how things are on the 32bit side of things, this is how it looks for 4.4.118
Code:
bash-4.3# ./spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.34+
Checking for vulnerabilities on current system
Kernel is Linux 4.4.118-smp #1 SMP Sun Feb 25 12:40:01 CST 2018 i686
CPU is Intel(R) Atom(TM) CPU N270 @ 1.60GHz
Possible disrepancy between your running kernel and the image we found (/boot/vmlinuz), results might be incorrect
Hardware check
* Hardware support (CPU microcode) for mitigation techniques
* Indirect Branch Restricted Speculation (IBRS)
* SPEC_CTRL MSR is available: NO
* CPU indicates IBRS capability: NO
* Indirect Branch Prediction Barrier (IBPB)
* PRED_CMD MSR is available: NO
* CPU indicates IBPB capability: NO
* Single Thread Indirect Branch Predictors (STIBP)
* SPEC_CTRL MSR is available: NO
* CPU indicates STIBP capability: NO
* Enhanced IBRS (IBRS_ALL)
* CPU indicates ARCH_CAPABILITIES MSR availability: NO
* ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
* CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO
* CPU microcode is known to cause stability problems: NO (model 28 stepping 2 ucode 0x20a)
* CPU vulnerability to the three speculative execution attacks variants
* Vulnerable to Variant 1: NO
* Vulnerable to Variant 2: NO
* Vulnerable to Variant 3: NO
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Kernel has array_index_mask_nospec: NO
* Checking count of LFENCE instructions following a jump in kernel... NO (only 0 jump-then-lfence instructions found, should be >= 30 (heuristic))
> STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable)
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
* Mitigation 2
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
* Retpoline enabled: YES
> STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable)
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface: NO (kernel confirms your system is vulnerable)
* Kernel supports Page Table Isolation (PTI): NO
* PTI enabled and active: NO
* Running as a Xen PV DomU: NO
> STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable)
A false sense of security is worse than no security at all, see --disclaimer
Possible disrepancy between your running kernel and the image we found (/boot/vmlinuz), results might be incorrect
Anyone know what that might be about? It comes from here [search for the word 'disrepancy'].
<<snip>>
Lysander666 --
The interesting line is because the Slackware Linux Kernel Installer Symlinks /boot/vmlinuz against the HUGE Kernel and you're apparently running GENERIC ?
If that is the case ( you're running GENERIC ), you can perhaps change the /boot/vmlinux symlink to point at your GENERIC Kernel but on the next Kernel Update,it will revert to HUGE ...
I suppose this is the safest assumption for Pat and the Team to make ( Assume HUGE -not- GENERIC ).
Note that there is a -k ( Kernel Override ) flag for spectre-meltdown-checker.sh ... check spectre-meltdown-checker.sh --help for details.
If that is the case ( you're running GENERIC ), you can perhaps change the /boot/vmlinux symlink to point at your GENERIC Kernel but on the next Kernel Update,it will revert to HUGE ...
Interesting thank you, and you are right, I am running generic. How do I change the symlink to point to generic? I've looked around but can't find the info I'm looking for.
I suppose this is the safest assumption for Pat and the Team to make ( Assume HUGE -not- GENERIC ).
No, it's because the kernel-huge package was installed after kernel-generic, which happens if you install them in alphabetical order. Both packages create the /boot/vmlinuz symlink, so whichever is installed last will win out.
To point to vmlinuz-generic instead, as root do:
Code:
cd /boot
rm vmlinuz
ln -s vmlinuz-generic vmlinuz
Edit: In the future, install the kernel-generic package AFTER the kernel-huge package, and /boot/vmlinuz will point to the generic kernel.
No, it's because the kernel-huge package was installed after kernel-generic, which happens if you install them in alphabetical order. Both packages create the /boot/vmlinuz symlink, so whichever is installed last will win out.
To point to vmlinuz-generic instead, as root do:
Code:
cd /boot
rm vmlinuz
ln -s vmlinuz-generic vmlinuz
Nice !
Thanks for that info drumz !
I'll change my install order from now on,
1. HUGE -then- GENERIC when I run GENERIC
2, GENERIC -then- HUGE when I run HUGE
No, it's because the kernel-huge package was installed after kernel-generic, which happens if you install them in alphabetical order. Both packages create the /boot/vmlinuz symlink, so whichever is installed last will win out.
To point to vmlinuz-generic instead, as root do:
Code:
cd /boot
rm vmlinuz
ln -s vmlinuz-generic vmlinuz
Edit: In the future, install the kernel-generic package AFTER the kernel-huge package, and /boot/vmlinuz will point to the generic kernel.
Excellent - it worked - thank you. I reran the checker and the notification didn't appear. And thanks for the advice about updating the kernel in the future.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,167
Original Poster
Rep:
Quote:
Originally Posted by Lysander666
Interesting thank you, and you are right, I am running generic. How do I change the symlink to point to generic? I've looked around but can't find the info I'm looking for.
Perhaps I'm over doing it, but with each kernel change I go to /boot and delete
the symbolic links and, if installing the generic kernel, the /boot/initrd-tree directory.
Linux version 4.15.6-local (build@magrathea) (gcc version 7.3.0 (GCC)) #1 SMP PREEMPT Sun Feb 25 21:57:39 GMT 2018
Well, that one didn't last very long.
Yeah, no kidding.
It certainly makes me appreciate Pat and the team more and more all the time ...
Fortunately, today's 4.4.119 Changelog looks like the good-ole ChangeLogs from before the Spectre && Meltdown Patch Frenzy.
The official Slackware64 14.2 linux-4.4.118 works so well, I'll not bother updating the other boxen on my LAN until there is something obviously security-related in the ChangeLog ( kick me sign firmly affixed to my back-side ).
Gotta say thanks to the team for the Slackware 14.2 linux-4.4.118 update !
-- kjh
This is my main Slackware64 14.2 + Multilib Laptop:
Code:
# uname -a
Linux kjhlt6 4.4.119.kjh #1 SMP Wed Feb 28 04:54:31 CST 2018 x86_64 Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz GenuineIntel GNU/Linux
Unfortunately I need CONFIG_SND_HDA_INPUT_BEEP=y which Pat doesn't enable, so even if I didn't want to make any other changes, or to run the latest stable rather than LTS, I can't use Pat's kernel as is.
If the patches look trivial I do skip releases, but they've been quite heavy of late so that's not really been an option.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
! THUNK ! 
