Originally posted by darkbasic
View Post
Announcement
Collapse
No announcement yet.
A Global Switch To Kill Linux's CPU Spectre/Meltdown Workarounds?
Collapse
X
-
Originally posted by apetresc View PostHow come `noretpoline` didn't make the list? Is it implicitly included in one of the other ones?
To check if you're currently using retpoline, type:
$ dmesg | grep 'retpoline'
If the above returns nothing, then no retpoline, but not necessarily not spectre v2 mitigation (done through microcode and kernel I believe)
Originally posted by darkbasic View Post"pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier"
Does it disable ALL the mitigations or some of them cannot be simply disabled?
On my machine, it shows:
$ ls -1A /sys/devices/system/cpu/vulnerabilities
l1tf
meltdown
spec_store_bypass
spectre_v1
spectre_v2
$ cat /sys/devices/system/cpu/vulnerabilities/*
Mitigation: PTE Inversion; VMX: vulnerable, SMT disabled
Vulnerable
Vulnerable
Mitigation: __user pointer sanitization
Vulnerable
and I have the boot parameters set in /etc/default/grub of:
GRUB_CMDLINE_LINUX_DEFAULT="quiet pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier"
If I check my init process, I can see it take effect:
$ ps aux | grep init
root 1 0.0 0.0 217960 9648 ? Ss Aug24 0:04 /sbin/init nospec_store_bypass_disable no_stf_barrier
To check if PTI is disabled, I can do:
$ dmesg | grep 'page tables isolation'
[ 0.000000] Kernel/User page tables isolation: disabled on command line.
Lastly, a more in depth scan can be done with spectre meltdown checker. Be sure to enable Strict Site Isolation in your browsers if you're going to disable these mitigations.
Originally posted by flower View Post
the microcode mitigations are not disabled. only way i know is to stay below version 22 - which is probably not a good idea
- Likes 4
Comment
-
Atleast with linux you have the options to disable unlike Win 10. I just had KB4100347 install on my AMD system and with the latest Windows there is no longer an option to hide it.
So now ever time I update windows I will have to manually uninstall this "fix" . As Steam Play matures my needs to boot to Windows will diminish alotThose who would give up Essential Liberty to purchase a little Temporary Safety,deserve neither Liberty nor Safety.
Ben Franklin 1755
- Likes 1
Comment
-
-
Of course, that's not recommended unless you really trust the code running on your system and the overall system security.
- Likes 2
Comment
-
I dont expect that the 2019 7nm ryzens will have the fixes in, this is still the Ryzen architecture just on 7nm, but I can be wrong, either way, the bugs and their performance impact are mostly a non issue on the AMD side.
- Likes 3
Comment
-
Originally posted by Ehvis View Post
If that's not the case, then the problem you have is probably a lot bigger than whatever spectre/meltdown can add to it. So far I have seen no compelling reason why a home user or gamer would be affected by spectre/meltdown at all.
This is not to even mention that meltdown can enable privilege escalation. This means that a user process or even a security sandboxed user process which is compromised by an attacker could gain access to kernel memory.
The vast majority of computer users should leave all these mitigations enabled.
Edit: Removed my comment that meltdown could also be used to "gain full control over the PC". I was mistaken about this: it might be achievable with some systems, but it's not a given that this can be done.Last edited by cybertraveler; 26 August 2018, 12:24 PM.
- Likes 3
Comment
-
For now the closest way to making an unmitigated kernel for not losing out on CPU performance would be booting the kernel with pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier. Of course, that's not recommended unless you really trust the code running on your system and the overall system security.
For any local linux desktop use these patches are total bullshit.
As a user you would only be very VERY VERY marginally more insecure by not having those patches. There are far easier ways to hack a user then to go though cpu bugs.
I stopped considering these patches as "sane" since the latest L1TF ones where disabling hyper-threading was a solution (thus crippling your performance). We basically get thrown back years in performance if we start applying those suggestion. This is just security paranoia that makes no sense at all anymore.
And i'm not being sarcastic here. I'm dead serious.
- Likes 6
Comment
-
Originally posted by markg85 View Post
all those patches only make sense in environments where you could have other users on the same cpu. So that would be cloud environment, a hosting provider, ... So the googles and amazons of this world are indeed better off applying those.
For any local linux desktop use these patches are total bullshit.
As a user you would only be very VERY VERY marginally more insecure by not having those patches. There are far easier ways to hack a user then to go though cpu bugs.
I stopped considering these patches as "sane" since the latest L1TF ones where disabling hyper-threading was a solution (thus crippling your performance). We basically get thrown back years in performance if we start applying those suggestion. This is just security paranoia that makes no sense at all anymore.
And i'm not being sarcastic here. I'm dead serious.
- Likes 2
Comment
Comment