Whonix vulerable due to missing processor microcode packages? spectre / meltdown / retpoline / L1 Terminal Fault (L1TF)

Patrick · January 29, 2020, 1:45pm

Automated test for Spectre/Meltdown

opened 04:26PM - 28 Aug 18 UTC

T: enhancement C: tests security P: default

### Qubes OS version: R4 ### Affected component(s): probably any Debian ba…sed TemplateVM (debian-9 tested by me), Whonix 14 (tested by me) not affected: Fedora --- ### Steps to reproduce the behavior: 1) install spectre-meltdown-checker from debian backports. (we have instructions handy [here](https://www.whonix.org/wiki/Firmware_Security_and_Updates#spectre-meltdown-checker)) 2) sudo spectre-meltdown-checker --paranoid ; echo $? ### Expected behavior: spectre-meltdown-checker saying `not vulnerable` and exiting with exit code `0` as it does in feodra-26. ### Actual behavior: https://forums.whonix.org/uploads/default/original/2X/d/d2ac1bb757b8d5963881dd05a44309c1a9272c44.png https://forums.whonix.org/uploads/default/optimized/2X/5/5fd8a2a129b1b4e1dbf53369fff347daa332f8cd_1_400x500.png ``` user@host:~$ sudo su -c "echo -e 'deb http://http.debian.net/debian stretch-backports main' > /etc/apt/sources.list.d/backports.list" user@host:~$ sudo apt-get update Hit:1 tor+http://sgvtcaew4bxjd7ln.onion stretch/updates InRelease Hit:2 tor+http://deb.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion stretch InRelease Ign:3 tor+http://vwakviie2ienjx6t.onion/debian stretch InRelease Hit:4 tor+http://vwakviie2ienjx6t.onion/debian stretch Release Hit:7 http://deb.qubes-os.org/r4.0/vm stretch InRelease Get:6 http://cdn-fastly.deb.debian.org/debian stretch-backports InRelease [91.8 kB] Get:8 http://cdn-fastly.deb.debian.org/debian stretch-backports/main amd64 Packages [409 kB] Get:9 http://cdn-fastly.deb.debian.org/debian stretch-backports/main Translation-en [301 kB] Get:10 http://cdn-fastly.deb.debian.org/debian stretch-backports/main amd64 Contents (deb) [4,885 kB] Fetched 5,686 kB in 36s (155 kB/s) Reading package lists... Done user@host:~$ sudo apt-get -t stretch-backports install spectre-meltdown-checker Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: spectre-meltdown-checker 0 upgraded, 1 newly installed, 0 to remove and 61 not upgraded. Need to get 33.4 kB of archives. After this operation, 139 kB of additional disk space will be used. Get:1 http://cdn-fastly.deb.debian.org/debian stretch-backports/main amd64 spectre-meltdown-checker all 0.39-1~bpo9+1 [33.4 kB] Fetched 33.4 kB in 1s (17.9 kB/s) Selecting previously unselected package spectre-meltdown-checker. (Reading database ... 80298 files and directories currently installed.) Preparing to unpack .../spectre-meltdown-checker_0.39-1~bpo9+1_all.deb ... Unpacking spectre-meltdown-checker (0.39-1~bpo9+1) ... Processing triggers for man-db (2.7.6.1-2) ... Setting up spectre-meltdown-checker (0.39-1~bpo9+1) ... user@host:~$ sudo spectre-meltdown-checker --paranoid ; echo $? Spectre and Meltdown mitigation detection tool v0.39 Checking for vulnerabilities on current system Kernel is Linux 4.14.57-1.pvops.qubes.x86_64 #1 SMP Mon Jul 23 16:28:54 UTC 2018 x86_64 CPU is Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz We're missing some kernel info (see -v), accuracy might be reduced Hardware check * Hardware support (CPU microcode) for mitigation techniques * Indirect Branch Restricted Speculation (IBRS) * SPEC_CTRL MSR is available: YES * CPU indicates IBRS capability: YES (SPEC_CTRL feature bit) * Indirect Branch Prediction Barrier (IBPB) * PRED_CMD MSR is available: YES * CPU indicates IBPB capability: YES (SPEC_CTRL feature bit) * Single Thread Indirect Branch Predictors (STIBP) * SPEC_CTRL MSR is available: YES * CPU indicates STIBP capability: YES (Intel STIBP feature bit) * Speculative Store Bypass Disable (SSBD) * CPU indicates SSBD 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 explicitly indicates not being vulnerable to Variant 4 (SSB_NO): NO * Hypervisor indicates host CPU might be vulnerable to RSB underflow (RSBA): NO * CPU microcode is known to cause stability problems: NO (model 0x3c family 0x6 stepping 0x3 ucode 0x24 cpuid 0x306c3) * CPU vulnerability to the speculative execution attack variants * Vulnerable to Variant 1: YES * Vulnerable to Variant 2: YES * Vulnerable to Variant 3: YES * Vulnerable to Variant 3a: YES * Vulnerable to Variant 4: YES CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1' * Mitigated according to the /sys interface: YES (Mitigation: __user pointer sanitization) * Kernel has array_index_mask_nospec: UNKNOWN (couldn't check (couldn't find your kernel image in /boot, if you used netboot, this is normal)) * Kernel has the Red Hat/Ubuntu patch: UNKNOWN (couldn't check (couldn't find your kernel image in /boot, if you used netboot, this is normal)) * Kernel has mask_nospec64 (arm64): UNKNOWN (couldn't check (couldn't find your kernel image in /boot, if you used netboot, this is normal)) * Checking count of LFENCE instructions following a jump in kernel... UNKNOWN (couldn't check (couldn't find your kernel image in /boot, if you used netboot, this is normal)) > STATUS: NOT VULNERABLE (Mitigation: __user pointer sanitization) CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2' * Mitigated according to the /sys interface: YES (Mitigation: Full generic retpoline, IBPB, IBRS_FW) * Mitigation 1 * Kernel is compiled with IBRS support: YES * IBRS enabled and active: YES (for kernel and firmware code) * Kernel is compiled with IBPB support: YES * IBPB enabled and active: YES * Mitigation 2 * Kernel has branch predictor hardening (arm): NO * Kernel compiled with retpoline option: YES * Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation) > STATUS: NOT VULNERABLE (Full retpoline + IBPB are mitigating the vulnerability) CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3' * Mitigated according to the /sys interface: YES (Mitigation: PTI) * Kernel supports Page Table Isolation (PTI): YES * PTI enabled and active: YES * Reduced performance impact of PTI: YES (CPU supports INVPCID, performance impact of PTI will be greatly reduced) * Running as a Xen PV DomU: NO > STATUS: NOT VULNERABLE (Mitigation: PTI) CVE-2018-3640 [rogue system register read] aka 'Variant 3a' * CPU microcode mitigates the vulnerability: NO > STATUS: VULNERABLE (an up-to-date CPU microcode is needed to mitigate this vulnerability) CVE-2018-3639 [speculative store bypass] aka 'Variant 4' * Mitigated according to the /sys interface: NO (Vulnerable) * Kernel supports speculation store bypass: YES (found in /proc/self/status) > STATUS: VULNERABLE (Your CPU doesn't support SSBD) Need more detailed information about mitigation options? Use --explain A false sense of security is worse than no security at all, see --disclaimer 2 user@host:~$ ``` Thanks to [TNT_BOM_BOM](https://forums.whonix.org/u/TNT_BOM_BOM) for [posting](https://forums.whonix.org/t/whonix-vulerable-due-to-missing-processor-microcode-packages/5739/26?u=patrick) the output of spectre-meltdown-checker. ### General notes: ``` > STATUS: NOT VULNERABLE (Mitigation: PTI) A false sense of security is worse than no security at all, see --disclaimer 0 ``` Is this just a false-positive or are Debian based VMs really vulnerable?

github.com/speed47/spectre-meltdown-checker

VirtualBox guest VM reports: an up-to-date CPU microcode is needed to mitigate this vulnerability

opened 11:33AM - 28 Jan 20 UTC

adrelanos

spectre-meltdown-checker `v0.42` `spectre-meltdown-checker --paranoid` on a D…ebian buster host: passed (exit code `0`) `spectre-meltdown-checker --paranoid` in a Debian buster VirtaulBox VM: failed > CVE-2018-3640 > an up-to-date CPU microcode is needed to mitigate this vulnerability This is likely a false-positive since VMs cannot alter CPU microcode? Or is this [this Virtualbox bug](https://www.virtualbox.org/ticket/17987)?

github.com/speed47/spectre-meltdown-checker

False positives inside Xen (PVH) domU

opened 06:16PM - 28 Jan 20 UTC

marmarek

doing

When running in Xen with SMT disabled (smt=0 Xen boot option), multiple points a…re still reported as vulnerable with "Your microcode and kernel are both up to date for this mitigation, but your must disable SMT (Hyper-Threading) for a complete mitigation". The same applies when SMT is disabled in BIOS. This is false positive, as in both cases Xen will never schedule anything on a secondary hyper-thread, so cross-hyper-threads attacks are not possible. I see the current SMT detection is done based on `/proc/cpuinfo`. Here is how it looks in this case: ``` grep '^proc\|^core\|^siblings\|^cpu cores' `/proc/cpuinfo` processor : 0 siblings : 2 core id : 0 cpu cores : 2 processor : 1 siblings : 2 core id : 1 cpu cores : 2 ``` In dom0 it looks the same (in this case both dom0 and domU has two (all) vCPUs). As you can see, each has a distinct `core id`. For comparison, here is how it looks with `smt=on` in (PV) dom0 and also dom0 having all (4 this time) vCPUs: ``` $ grep '^proc\|^core\|^siblings\|^cpu cores' /proc/cpuinfo processor : 0 siblings : 4 core id : 0 cpu cores : 2 processor : 1 siblings : 4 core id : 0 cpu cores : 2 processor : 2 siblings : 4 core id : 1 cpu cores : 2 processor : 3 siblings : 4 core id : 1 cpu cores : 2 ``` Here, you see each `core id` value appears twice. Unfortunately, if I take a domU with 2 or 4 vCPUs, I get distinct `core id` each time, for example: ``` $ grep '^proc\|^core\|^siblings\|^cpu cores' /proc/cpuinfo processor : 0 siblings : 4 core id : 0 cpu cores : 4 processor : 1 siblings : 4 core id : 1 cpu cores : 4 processor : 2 siblings : 4 core id : 2 cpu cores : 4 processor : 3 siblings : 4 core id : 3 cpu cores : 4 ``` This is because (I think) `/proc/cpuinfo` is based mostly on ACPI, which is constructed by Xen toolstack, with only some info taken from the real hardware. I don't know if there is any reliable method of detecting from within domU whether SMT is enabled in Xen or not. I've also taken look at `/sys/devices/system/cpu/smt/control` and `/sys/devices/system/cpu/smt/active`: |real SMT state | domain | `.../control` | `.../active` | |-|-|-|-| |off|dom0 (PV) | `on` | `0` | |off|domU (PVH) | `on` | `0` | |off|domU (PV) | `on` | `1` | |on|dom0 (PV) | `on` | `1` | |on|domU (PVH) | `on` | `0` | |on|domU (PV) | `on` | `1` | As you can see, PVH always sees SMT as disabled. And PV domU always sees it enabled. BTW the script search for `SMT (disabled|mitigated)` in dmesg, which doesn't always match those sysfs entries. Especially here even if `active` is `0`, there is no such line in `dmesg`. Until some method is found, I propose modifying `is_cpu_smt_enabled` to return 2 (unknown) if Xen (PVH) domU is detected.

As far as VirtualBox is concerned… Quote Spectre Meltdown - Whonix

There is no solution for VirtualBox yet. The bug has been reported to the VirtualBox developers. See VirtualBox 5.2.18 vulnerable to spectre/meltdown despite microcode being installed [archive]. The Whonix ™ developers depend on the VirtualBox developers for fixing this VirtualBox issue. Nevertheless: […]

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.