CVE-2018-12126 [microarchitectural store buffer data sampling (MSBDS)] aka ‘Fallout’
CVE-2018-12130 [microarchitectural fill buffer data sampling (MFBDS)] aka ‘ZombieLoad’
CVE-2018-12127 [microarchitectural load port data sampling (MLPDS)] aka ‘RIDL’
CVE-2019-11091 [microarchitectural data sampling uncacheable memory (MDSUM)] aka ‘RIDL’
Kernel update doesn’t fix this CVE, to fix this it’s needed to install intel-microcode.
What we do ? Install intel-microcode to host, whonix-gateway and whonix-workstation or do not install intel-microcode ?
Thank you. I ask because some months ago I saw on this forum a post like this:
"Don’t install intel-microcode to fix spectre and meltdown, new microcode can contain new backdoors. Just update your kernel "
Not installing microcode only leaves known vulnerabilities (= for all practical purposes the same like a backdoors - just known by much more people) remain.
The cold hard truth is that CPU is fully trusted, i.e. has ultimate control. We can only patch some known vulnerabilities at the mercy of the producers.
The solution can most likely could only be non-technical:
Smash Intel/AMD using anti-trust law [not great, but also not too bad].
Allow emerging competition by removing market entrance barriers such as copyright and patent law. [It didn’t happen until now that a new company could compete with existing armies of copyright and patent lawyers and I predict it won’t happen unless laws are softened to allow competition or unless at least some country allows for such an environment. The required investment seems to high, too difficult, too risky, too low return of investment.]
Just patch host and get sure spectre-meltdown checker returns NOT VULNERABLE status for all vulnerabilities.
After that if you boot guest and and run spectre-meltdown checker you will see VULNERABLE status for most vulnerabilities. Might be because CPU is being detected as CPU is QEMU Virtual CPU version. So is guest vulnerable in this case ?
Some of these mitigations are available “optionally.” I mean like in the case of Vbox, as an example, the L1Df vuln can be mitigated on a per machine basis on commandline using “VBoxManage modifyvm…”
There are 4 total commands specific to this particular vuln, and documentation says “perf degradation can be SEVERE…”
I have these options enabled in my machines, including Whonix and do not notice any performance issues. Perhaps others would? I guess the chip makes a difference?
Commands: --l1d-flush-on-vm-entry on, --l1d-flush-on-sched on, --ibpb-on-vm-entry on, --ibpb-on-vm-exit on.
There is also a set of commands for other vulns that I have not enabled. According to logs on non-Whonix Debian virtual machines, with the above commands enabled, spectre v1 and v2 are mitigated, MDS is mitigated using a clearing of cpu buffers, but warns for full mitigation to turn off smt (hyperthreading). It lists Spec. Store bypass a still vulnerable though. Since Spec. Store Bypass has been mitigated on the host through a microcode update, is the VM still vulnerable? I am not sure.
On my host(s), everything is mitigated.
A copy of the vm logs:
Jan 28 20:33:32 host kernel: Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
Jan 28 20:33:32 host kernel: Spectre V2 : Mitigation: Full generic retpoline
Jan 28 20:33:32 host kernel: Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch
Jan 28 20:33:32 host kernel: Speculative Store Bypass: Vulnerable
Jan 28 20:33:32 host kernel: MDS: Mitigation: Clear CPU buffers
Observations:
I notice that MDS mitigates along the same lines in the VM as on the hosts. Like if you mitigate mds on host, the virtual machine follows that and displays the same mitigation in the virtual machine. The Speculative Store Bypass does not for some reason, despite being mitigated on the host. Interesting though that for MDS, there is an associated VBoxManage command, 2 of them to clear on vm entry and/or on vm exit. There is also a --spec-ctl on | off option as well which I do not have enabled on the VMs.
On the Debian VMs, the only vulns listed as active is Speculative Store Bypass, and something called itlb_multithit according to /sys/devices/system/cpu/vulnerabilities. There is an entry for tsx_async_abort but it says “Not affected” inside the file. Obviously disabling hyperthreading on the host would take care of itlb_multihit. When it (hyperthreading) is disabled, the Debian VM is not vulnerable anymore.
Yes. Enabling those VirtualBox spectre/meltdown related security settings makes a VirtualBox Whonix-Gateway VM notifibly slow and the fan of my otherwise powerful notebook turns on.
Interesting, creating a “40_spec_disable.cfg” in the /etc/default/grub.d folder with the spec_store_bypass_disable=on configuration and then updating grub showed on a reboot that it had no effect. The log still reported:
Speculative Store Bypass: Vulnerable
(The host is appropriately patched and not vulnerable)
Interesting, creating a “40_spec_disable.cfg” in the /etc/default/grub.d folder with the spec_store_bypass_disable=on configuration and then updating grub showed on a reboot that it had no effect.
Shows up in cat /proc/cmdline?
The log still reported:
Speculative Store Bypass: Vulnerable
(The host is appropriately patched and not vulnerable)
.