Do you use any spectre-meltdown mitigation kernel paramater?

[Danielsan]

As for the title, are you adding any special grub parameter like:

Code: Select all

MITIGATION=AUTO

Or are those mitigations now applied by default in Debian?

Thanks,

D.

[Deb-fan]

Fairly well sure the mitigations are enabled default (99.999%) though too lazy to check the default config file. Atm using a stock kernel, mostly I do go ahead and custom compile them just cause it's something I prefer doing and formerly have taken to actually disabling mitigation measures such as retpoline and pti or whatever else ...

Said it many times and places already, the endless side-channel junk in my view isn't so much relevant to desktop nixers, many nixers in many other environments either. Mostly a much bigger deal in shared hardware, multi-user settings. VPS's, cloud-computing, that type of thing. Where many unknown people are sharing the same hardware, not a single-user or a few known non-malicious users sharing a system.

Same time, with more and more of them being discovered/emerging, think for a nixer with an affected Intel cpu, as long as there's no real significant performance hit in how you use your pc, what someone is using it for, then better safe than sorry.

2 cents.

[Head_on_a_Stick]

are those mitigations now applied by default in Debian?

Check for yourself:

Code: Select all

grep -R . /sys/devices/system/cpu/vulnerabilities

[Deb-fan]

^ Interesting output ... Should check further ... don't care enough about speculative execution stuff to bother. Dumped enough time researching the topic already. Oops, edit: Though guess it can't hurt to at least be aware of, in case it were to ever become important. Was assuming it'd be error on the side of caution though if this is standard config, then the folks with the Debian project who make such decisions went the other way ??

Most likely at some point would've gotten around to setting param's to disable the mitigations or compiled them out anyway.

4 cents.

[Danielsan]

are those mitigations now applied by default in Debian?

Check for yourself:

Code: Select all

grep -R . /sys/devices/system/cpu/vulnerabilities

With MITIGATION=AUTO
--------------------------------

Code: Select all

grep -R . /sys/devices/system/cpu/vulnerabilities
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling
/sys/devices/system/cpu/vulnerabilities/itlb_multihit:KVM: Mitigation: VMX disabled
/sys/devices/system/cpu/vulnerabilities/mds:Mitigation: Clear CPU buffers; SMT vulnerable
/sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Mitigation: Clear CPU buffers; SMT vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/srbds:Mitigation: Microcode
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI

No entry
--------------

Code: Select all

grep -R . /sys/devices/system/cpu/vulnerabilities
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling
/sys/devices/system/cpu/vulnerabilities/itlb_multihit:KVM: Mitigation: VMX disabled
/sys/devices/system/cpu/vulnerabilities/mds:Mitigation: Clear CPU buffers; SMT vulnerable
/sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Mitigation: Clear CPU buffers; SMT vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/srbds:Mitigation: Microcode
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI

Is the same...

[Head_on_a_Stick]

As you appear to have been tricked into buying Intel's garbage I would recommend disabling SMT by adding this line to /etc/sysfs.conf (or in it's own file under /etc/sysfs.d/):

Code: Select all

devices/system/cpu/smt/control = off

OpenBSD have been doing this by default since Meltdown was discovered. It will reduce performance for multi-threaded applications but increase performance if only a single thread is being used.

[LE_746F6D617A7A69]

Playing a devil's advocate here:

All the spectre-related vulnerabilities are based on the precise CPU cache access timing - they were <partially> eliminated by disabling precision timers in the web-browsers (main source of the worst-case attacks)

Not only Intel CPUs are prone to such kind of attacks, AMD is vulnerable as well - the only difference is that for AMD it's much harder to find the exact timing, so statistically, AMD CPUs are more safe (but f.e. even with mitigations applied, it's still possible to attack AMD Phenom CPUs)

Anyway, the whole rush about the spectre-class vulnerabilities is just another way to suck money from the customers: while it is possible to catch some random data from the caches, that data is practically useless - the probability to find any useful string of bytes is practically zero.

But, this "vulnerability" have caused that many people have decided to upgrade their PCs - another billion of CPUs has been sold

[Head_on_a_Stick]

Not only Intel CPUs are prone to such kind of attacks, AMD is vulnerable as well - the only difference is that for AMD it's much harder to find the exact timing, so statistically, AMD CPUs are more safe (but f.e. even with mitigations applied, it's still possible to attack AMD Phenom CPUs)

AMD processors are not susceptible to as wide a range of attacks as Intel's crap; this is from my Ryzen 2500U machine:

Code: Select all

$ grep -R . /sys/devices/system/cpu/vulnerabilities
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full AMD retpoline, IBPB: conditional, STIBP: disabled, RSB filling
/sys/devices/system/cpu/vulnerabilities/itlb_multihit:Not affected
/sys/devices/system/cpu/vulnerabilities/mds:Not affected
/sys/devices/system/cpu/vulnerabilities/l1tf:Not affected
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Not affected
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/srbds:Not affected
/sys/devices/system/cpu/vulnerabilities/meltdown:Not affected
$

Note that RISC-V doesn't perform speculative execution and so is completely immune: https://riscv.org/blog/2018/01/more-sec ... isc-v-isa/

And yes, browsers can still be vulnerable even with the mitigations applied. Test your system here: https://leaky.page/

[Danielsan]

As you appear to have been tricked into buying Intel's garbage I would recommend disabling SMT by adding this line to /etc/sysfs.conf (or in it's own file under /etc/sysfs.d/):

Code: Select all

devices/system/cpu/smt/control = off

OpenBSD have been doing this by default since Meltdown was discovered. It will reduce performance for multi-threaded applications but increase performance if only a single thread is being used.

If I disable that voice I drop down four cores entirely...

[CwF]

Disabling in the bios is superior. The remaining cores get more power than the software switch...