What about something like kvm64? Should be supported for both Intel and AMD. I don’t know what features are not supported, at least aes it seems, but maybe we could live with that?
According to this old thread: Guest systems sees CPU of the Host - #17 by nurmagoz
@nurmagoz results show Xen and VBox accessing the majority of host flags. Test by diffing the Dom0/DomU output for cat /proc/cpuinfo
A reference on the inability of guests to manipulate microcode. Different from the paper I read a long time ago and too lazy to dig up.
b) “Qubes and VirtualBox need CPU passthrough enabled, and microcode packages installed, otherwise they’d be vulnerable.”
Yes and I’d add: microcode on Dom0/host (which is not a virtualized Whonix’s concern). Whonix physical build needs the microcode.
Reference is post above with select quotes:
Host passthrough
This is the recommended CPU to use, provided live migration is not required.
The following are important CPU features that should be used on Intel x86 hosts, when available in the host CPU. … In general all of these features are included if using “Host passthrough” or “Host model”.
On kvm64:
their usage is discouraged, as they expose a very limited featureset, … First as mentioned kvm64 is an ancient CPU model, pretty much awful as qemu64. If they [guest kernels] see kvm64 they’ll think the CPU is so old that no mitigations are needed, even if you did turn on spec-ctrl feature. So the guest OS will likely remain vulnerable.
1 Like
https://www.berrange.com/posts/2018/06/29/cpu-model-configuration-for-qemu-kvm-on-x86-hosts/
With the various CPU hardware vulnerabilities reported this year, guest CPU configuration is now a security critical task.
That is an interesting quote indeed.
That is
“Qubes dom0 (host) and VirtualBox host need microcode packages installed, otherwise they’d be vulnerable. VM does not need microcode packages installed”?
Yes, until that point, agreed.
Yes.
“Qubes dom0 (host) and VirtualBox host need microcode packages installed and they need to use CPU passthorugh, otherwise they’d be vulnerable.” -
?
That’s really big.
I haven’t found any reference stating CPU passthrough is required. linux - Are CPU microcode updates always ignored by Hypervisors? - Server Fault doesn’t talk say “CPU passthrough required” or so either.
There should be discussions and bug reports upstream if that is the case.
Dan Berrange’s post does say that as far as KVM and I assume it applies to all hypervisors. Since we saw from tests that they don’t mask anything out by default that’s not a problem. There is nothing to fix.
All this thread substantiates is that you can’t change microcode from inside a guest for security reasons (which makes sense). This applies to any hypervisor worth its salt.
The necessity for passthrough to take advantage of updated microcode comes from my other reference.
1 Like
I read that post multiple times but initially was (and I am still) worried about the “likely” which to me sounds like guessing and noone actually tested it. However, I certainly see a point in using host-model/passthrough instead of kvm64 for performance reasons.
I just made a test with the spectre-meltdown-checker script from the official debian package. While the host showed “not vulnerable” to all listed CVEs an updated Whonix KVM guest with the respective CPU features enabled in the xml was always vulnerable to CVE-2018-3640 and CVE-2018-3639. 3640 should be fixed by microcode update. 3639 should be fixed with the ssbd feature, but I could not pass it to the VM for whatever reason despite it being available on the host. Changing models to host-passthrough or kvm64 did not change anything. Maybe someone can test the script on qubes or on some other machines.
1 Like
Assumption is too quick here. Virtualizers are very different. KVM is inside Linux kernel and Qubes (Xen) is a microkernel. A good pointer for research very much so indeed.
Quote https://download.virtualbox.org/virtualbox/5.2.18/UserManual.pdf / Chapter 8. VBoxManage
--ibpb-on-vm-[enter|exit] on|off: Enables flushing of the indirect branch prediction buffers on every VM enter or exit respectively. This could be enabled by users overly worried about possible spectre attacks by the VM. Please note that these options may have sever impact on performance.
Have to research a lot more but this sounds very bad at first. “Enables” implies “not enabled by default” and “could be enabled by users overly worried about possible spectre attacks” indicates Oracle VirtualBox taking the position as Intel with “Indirect Branch Predictor Barrier (IBPB) is a security feature”.
https://download.virtualbox.org/virtualbox/5.2.6/UserManual.pdf does not contain mentioning of spectre.
Related:
http://lkml.iu.edu/hypermail/linux/kernel/1801.2/04628.html
Quote Chapter 8. VBoxManage
--ibpb-on-vm-[enter|exit] on|off: Enables flushing of the indirect branch prediction buffers on every VM enter or exit respectively. This could be enabled by users overly worried about possible spectre attacks by the VM. Please note that these options may have sever impact on performance.
--ibpb-on-vm-enter on--ibpb-on-vm-exit on
--spec-ctrl on|off: This setting enables/disables exposing speculation control interfaces to the guest, provided they are available on the host. Depending on the host CPU and workload, enabling speculation control may significantly reduce performance.
--l1d-flush-on-sched on|off: Enables flushing of the level 1 data cache on scheduling EMT for guest execution. See Section 13.4.1, “CVE-2018-3646”.
Qubes R4 Debian VM:
sudo journalctl | grep -i spectre
Aug 27 14:04:24 localhost kernel: Spectre V2 : Mitigation: Full generic retpoline
Aug 27 14:04:24 localhost kernel: Spectre V2 : Spectre v2 mitigation: Enabling Indirect Branch Prediction Barrier
Aug 27 14:04:24 localhost kernel: Spectre V2 : Enabling Restricted Speculation for firmware calls
Same for Qubes Whonix 14. Same for Qubes fedora-26. Same for Qubes dom0.
Documentation for further diagnosis just now written:
1 Like
What is the output of the spectre-meltdown-checker script?
but there is accessibility to the code, anyone who have knowledge about it will fix it/patching it …etc. Not something from an evil company like Intel.
package not installed in our system = so no backdoor.
for the vulnerability affect, whether we have it or not it will not defend it unless the host support that like Qubes or plain Debian …etc. since Whonix is not a host OS (yet or maybe never) so adding an outsides packages is nonsense from security pointview.
Also if this is a critial issue for all Distros , then Debian for sure will search away to add this package inside their main repo. and if they didnt then this is something not really worth for us to make it superior.
according to the test mentioned in the wiki
- Results here (before “intel-microcode”): (Test Done on Whonix 14 - Qubes)
Welcome to Whonix!
https://www.whonix.org
The programs included with the Whonix GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Whonix GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law. Whonix is a derivative of Debian GNU/Linux.
Whonix is based on Tor. Whonix is produced independently from the
Tor (r) anonymity software and carries no guarantee from The Tor Project
about quality, suitability or anything else.
Whonix is experimental software by means of concept and design.
Do not rely on it for strong anonymity.
Type: "whonix" <enter> for help.
uwt INFO: Stream isolation for some applications enabled. uwt / torsocks will be automatically prepended to some commands. What is that? See:
uwt INFO: https://www.whonix.org/wiki/Stream_Isolation/Easy
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:~$
- Results after installing “intel-microcode”:
Welcome to Whonix!
https://www.whonix.org
The programs included with the Whonix GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Whonix GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law. Whonix is a derivative of Debian GNU/Linux.
Whonix is based on Tor. Whonix is produced independently from the
Tor (r) anonymity software and carries no guarantee from The Tor Project
about quality, suitability or anything else.
Whonix is experimental software by means of concept and design.
Do not rely on it for strong anonymity.
Type: "whonix" <enter> for help.
uwt INFO: Stream isolation for some applications enabled. uwt / torsocks will be automatically prepended to some commands. What is that? See:
uwt INFO: https://www.whonix.org/wiki/Stream_Isolation/Easy
user@host:~$ sudo apt-get install intel-microcode
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
initramfs-tools initramfs-tools-core iucode-tool klibc-utils libklibc linux-base
The following NEW packages will be installed:
initramfs-tools initramfs-tools-core intel-microcode iucode-tool klibc-utils libklibc linux-base
0 upgraded, 7 newly installed, 0 to remove and 0 not upgraded.
Need to get 1,561 kB of archives.
After this operation, 2,564 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 tor+http://vwakviie2ienjx6t.onion/debian stretch/main amd64 libklibc amd64 2.0.4-9 [52.6 kB]
Get:2 tor+http://sgvtcaew4bxjd7ln.onion stretch/updates/non-free amd64 intel-microcode amd64 3.20180703.2~deb9u1 [1,165 kB]
Get:3 tor+http://vwakviie2ienjx6t.onion/debian stretch/main amd64 klibc-utils amd64 2.0.4-9 [108 kB]
Get:4 tor+http://vwakviie2ienjx6t.onion/debian stretch/main amd64 initramfs-tools-core all 0.130 [97.0 kB]
Get:5 tor+http://vwakviie2ienjx6t.onion/debian stretch/main amd64 linux-base all 4.5 [19.1 kB]
Get:6 tor+http://vwakviie2ienjx6t.onion/debian stretch/main amd64 initramfs-tools all 0.130 [66.0 kB]
Get:7 tor+http://vwakviie2ienjx6t.onion/debian stretch/contrib amd64 iucode-tool amd64 2.1.1-1 [53.3 kB]
Fetched 1,561 kB in 7s (196 kB/s)
Preconfiguring packages ...
Selecting previously unselected package libklibc.
(Reading database ... 80304 files and directories currently installed.)
Preparing to unpack .../0-libklibc_2.0.4-9_amd64.deb ...
Unpacking libklibc (2.0.4-9) ...
Selecting previously unselected package klibc-utils.
Preparing to unpack .../1-klibc-utils_2.0.4-9_amd64.deb ...
Adding 'diversion of /usr/share/initramfs-tools/hooks/klibc to /usr/share/initramfs-tools/hooks/klibc^i-t by klibc-utils'
Unpacking klibc-utils (2.0.4-9) ...
Selecting previously unselected package initramfs-tools-core.
Preparing to unpack .../2-initramfs-tools-core_0.130_all.deb ...
Unpacking initramfs-tools-core (0.130) ...
Selecting previously unselected package linux-base.
Preparing to unpack .../3-linux-base_4.5_all.deb ...
Unpacking linux-base (4.5) ...
Selecting previously unselected package initramfs-tools.
Preparing to unpack .../4-initramfs-tools_0.130_all.deb ...
Unpacking initramfs-tools (0.130) ...
Selecting previously unselected package iucode-tool.
Preparing to unpack .../5-iucode-tool_2.1.1-1_amd64.deb ...
Unpacking iucode-tool (2.1.1-1) ...
Selecting previously unselected package intel-microcode.
Preparing to unpack .../6-intel-microcode_3.20180703.2~deb9u1_amd64.deb ...
Unpacking intel-microcode (3.20180703.2~deb9u1) ...
Setting up libklibc (2.0.4-9) ...
Setting up linux-base (4.5) ...
Setting up iucode-tool (2.1.1-1) ...
Processing triggers for man-db (2.7.6.1-2) ...
Setting up intel-microcode (3.20180703.2~deb9u1) ...
intel-microcode: initramfs support missing
Setting up klibc-utils (2.0.4-9) ...
Setting up initramfs-tools-core (0.130) ...
Setting up initramfs-tools (0.130) ...
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools (0.130) ...
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:~$
- Conclusion:
It has Zero effect.
1 Like
I thought it only matters on the host OS?
yeah thats why its useless to add it inside whonix and thats what im saying. whonix has nothing to do with this vulnerability at all. adding non-free package should be something unquestionable and the answer = always denial.
1 Like
We fixed the docs (pending edits) - my mistake. Does nothing inside the VM.
1 Like
package not installed in our system = so no backdoor.
for the vulnerability affect, whether we have it or not it will not defend it unless the host support that like Qubes or plain Debian …etc.
We might not need the microcode packages inside the VM. I am not totally sure about it yet. Still researching. However, we might have to switch some settings in VirtualBox (As mentined in my post earlier in this thread Whonix vulerable due to missing processor microcode packages? spectre / meltdown / retpoline / L1 Terminal Fault (L1TF) - #22 by Patrick) and perhaps other virtualizers. In other words, there could be vulnerable VM settings. Thanks for bringing this to attention!
Also if this is a critial issue for all Distros , then Debian for sure will search away to add this package inside their main repo.
They will never manage to do this. Not anytime soon. There is no Libre Software processor microcode project as far as I know since processor vendors are non-cooperative, this requires reverse engineering, and for processor microcode this is one among the most difficult tasks.
Awesome, thanks for collecting the output, that saved me some time reporting a Qubes issue I was going to report.
2 Likes
True and your documentation finds indicate that this is indeed the case. VBox lacks these by default it seems.
Test Conditions: KVM. Microcode installed on host. spectre-meltdown-checker used. Variable tested is cpu passthrough to guest and without.
Summary:
Guests better off using CPU passthrough as far as KVM is concerned.
HOST:
‘Spectre Variant 1’ STATUS: NOT VULNERABLE
‘Spectre Variant 2’ STATUS: VULNERABLE
‘Spectre Variant 3’ STATUS: NOT VULNERABLE
‘Spectre Variant 3a’ STATUS: NOT VULNERABLE
‘Spectre Variant 4’ STATUS: NOT VULNERABLE
GUEST PASSTHROUGH:
‘Spectre Variant 1’ STATUS: NOT VULNERABLE
‘Spectre Variant 2’ STATUS: VULNERABLE
‘Spectre Variant 3’ STATUS: NOT VULNERABLE
‘Spectre Variant 3a’ STATUS: NOT VULNERABLE
‘Spectre Variant 4’ STATUS: NOT VULNERABLE
GUEST WITHOUT PASSTHROUGH:
‘Spectre Variant 1’ STATUS: NOT VULNERABLE
‘Spectre Variant 2’ STATUS: VULNERABLE
‘Spectre Variant 3’ STATUS: NOT VULNERABLE
‘Spectre Variant 3a’ STATUS: NOT VULNERABLE
‘Spectre Variant 4’ STATUS: VULNERABLE
1 Like
Two observations:
-
Installing the microcode package from backports is necessary as the one in stable is outdated and frozen for almost 2 years.
-
Even with the microcode installed its not guaranteed that its being used by the system for one reason or another such as the UEFI firmware overriding or rejecting it or it being disabled by upstream because of stability problems.
Compare your microcode version number before and after updating to see if its applied:
sudo dmesg | grep "microcode updated early to"
If it succeeded it should say something like:
microcode: microcode updated early to revision X
https://wiki.debian.org/Microcode#Checking_the_microcode_version_of_your_CPU
2 Likes
Shouldn’t security updates be backported?
Anyways, I tried to integrate the microcode packages during the build and make Depends architecture specific. While this works in theory in practice it interfers with the Whonix build process/dpkg and it will fail.
Options would be:
- Install the package manually for the cli version of the gateway
- Fix the build process. Not sure how feasible this would be or if setting Architecture for the meta-package to amd64 and arm64 would help.
- Don’t use the non-qubes-whonix-gateway-cli as Depends for the rpi gateway but the other meta-packages instead.
I’d sort of vote for option 3.
1 Like
For physically isolated / bare metal version, install manually yes, that’s an ok solution.
(Note: Not each cli gateway is bare metal. There’s also demand for a Whonix-Gateway-CLI VM.)
Build Documentation: Physical Isolation already documents to manually install it.
When using the Whonix build scirpt --target root we could install the package. I am not sure Build Documentation: Physical Isolation is important enough but I would accept a patch.
non-qubes-whonix-gateway-cli package may not be best indeed due to usable for CLI VM.
whonix-gateway-rpi could depend on it?