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.
Distribution: Slackware64 15.0 (started with 13.37). Testing -current in a spare partition.
Posts: 928
Rep:
Quote:
Originally Posted by Lysander666
In 64bit. 32bit users are being rather left behind here. No mitigation for Meltdown as yet.
I think they should release all fixes at same time, at least for the same kernel version.
Is that because Meltdown affects only Intel? Maybe it is hard to fix.
4.14.18 and 4.15.2 for x86_64 seem ok now.
Code:
root@paulobash~# cat 4.14.18-x86_64
/sys/devices/system/cpu/vulnerabilities/meltdown: Not affected
/sys/devices/system/cpu/vulnerabilities/spectre_v1: Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2: Mitigation: Full AMD retpoline
root@paulobash~# cat 4.15.2-custom-x86_64
/sys/devices/system/cpu/vulnerabilities/meltdown: Not affected
/sys/devices/system/cpu/vulnerabilities/spectre_v1: Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2: Mitigation: Full AMD retpoline
While I am still vulnerable to Spectre Variant 1 ( see below ), there are a couple worthwhile backports into 4.4.116 for AMD and AMD hypervisors.
From the 4.4.116 ChangeLog:
Code:
commit ba929f5f3c263f3b975a3b95328f66203a57b536
Author: Borislav Petkov <bp@suse.de>
Date: Thu Oct 12 13:23:16 2017 +0200
x86/microcode: Do the family check first
commit 1f161f67a272cc4f29f27934dd3f74cb657eb5c4 upstream with adjustments.
On CPUs like AMD's Geode, for example, we shouldn't even try to load
microcode because they do not support the modern microcode loading
interface.
...
and
Code:
commit 3fe9cdee4205a4876154f469247c7a3176ccaac7
Author: Borislav Petkov <bp@suse.de>
Date: Sun Dec 18 17:44:13 2016 +0100
x86/microcode/AMD: Do not load when running on a hypervisor
commit a15a753539eca8ba243d576f02e7ca9c4b7d7042 upstream with minor
adjustments.
Doing so is completely void of sense for multiple reasons so prevent
it. Set dis_ucode_ldr to true and thus disable the microcode loader by
default to address xen pv guests which execute the AP path but not the
BSP path.
...
And sccording to the latest spectre-meltdown-checker.sh
Code:
# /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.116.kjh #1 SMP Sat Feb 17 07:20:06 CST 2018 x86_64
CPU is Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
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 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: NO (kernel confirms your system is vulnerable)
* Kernel has array_index_mask_nospec: NO
* Kernel has the Red Hat/Ubuntu patch: NO
* Checking count of LFENCE instructions following a jump in kernel... NO (only 15 jump-then-lfence instructions found, should be >= 30 (heuristic))
> STATUS: VULNERABLE (Kernel source needs to be patched to mitigate the vulnerability)
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
I've done some tests with new kernels 4.14, I think nouveau devs made lots of progress in between 4.4 and 4.14
For example this one card that I have reported only 512 MiB with kernel 4.4.115 but on 4.14.x it reports the true value:
I've done some tests with new kernels 4.14, I think nouveau devs made lots of progress in between 4.4 and 4.14
For example this one card that I have reported only 512 MiB with kernel 4.4.115 but on 4.14.x it reports the true value:
Code:
nouveau 0000:01:00.0: DRM: VRAM: 1024 MiB
There was a lot of progress done around 4.10 and after in regards to reclocking.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.