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

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

@nurmagoz:

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

VirtualBox testers wanted!

Whonix ™ for Windows, macOS, Linux inside VirtualBox

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:

  1. Install the package manually for the cli version of the gateway
  2. 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.
  3. 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?

Since in Whonix vulerable due to missing processor microcode packages? spectre / meltdown / retpoline / L1 Terminal Fault (L1TF) - #32 by HulaHoop you were using packages from stretch rather than stretch-backports… And since in Whonix vulerable due to missing processor microcode packages? spectre / meltdown / retpoline / L1 Terminal Fault (L1TF) - #34 by HulaHoop you said you were using backports now…

Could you please make a post similar to Whonix vulerable due to missing processor microcode packages? spectre / meltdown / retpoline / L1 Terminal Fault (L1TF) - #32 by HulaHoop @HulaHoop

VirtualBox on Linux Hosts forum:
VirtualBox 5.2.18 vulnerable to spectre/meltdown despite microcode being installed
https://forums.virtualbox.org/viewtopic.php?f=7&t=89395

1 Like

In my case, my machine is refusing to apply any microcode package of any version and that’s why I made the extra warnings and caveats about checking if its really applied in my last post. I discovered that only backports had the fixes by reading the package log file and comparing it to the stable version. This post just shows that switching to passthrough allows more host kernel mitigations to apply to the guest.

Absolutely. I think this was overlooked by the maintainer/Debian security team somewhere.

Qubes (and by extension Qubes-Whonix) is no longer vulnerable after dom0 upgrades.

spectre-meltdown-checker saying vulnerable inside Debian based Qubes VMs · Issue #4262 · QubesOS/qubes-issues · GitHub

1 Like

Created a whonixcheck test.

https://github.com/Whonix/whonixcheck/commit/4d65231b87b1dbc7827cd47c86f1f4d5476bcda2

Test not yet enabled by default. Package not updated yet.

whonixcheck --verbose --cli --gui --function check_spectre_meltdown

Will enable by default later. Only for platforms where this is fixable? Or all? Let’s suppose it can only be fixed in Qubes but not VirtualBox / KVM? We tell users about it “not our fault, but well, trash your hardware if you can’t fix it if you want to be secure”?

Wording suggestions welcome since this could be a major source of support requests.

WARNING: Spectre Meltdown Test Result: Vulnerable.

Technical information:
sudo spectre-meltdown-checker --paranoid
exited with code 1.

Recommendation:
See Spectre Meltdown - Whonix.

(The part WARNING: is not flexible. It’s either INFO:, WARNING: or ERROR:. All other text is flexible.)

3 Likes

Enable it for all and then link to a wiki page that lists advice for all hypervisors we support.

KVM Is fixable it just happens my hardware has a problem accepting the microcode not a general problem for everyone. Also the next release will have passthrough enabled making the default config safe for consumption.

1 Like

Alright. Will enable for everyone by default.

Updated wording:

WARNING: Spectre Meltdown Test Result: Vulnerable.

Technical information:
sudo spectre-meltdown-checker --paranoid
exited with code 1.

Recommendation:
See Spectre Meltdown - Whonix.

If you know what you are doing, feel free to disable this check. Create a file /etc/whonix.d/50_whonixcheck_user.conf and add:

whonixcheck_skip_functions+=" check_spectre_meltdown "

Please populate Spectre Meltdown - Whonix with platform specific instructions etc., i.e. how to modify existing VMs settings, keep in mind multiple VMs.

1 Like

spectre-meltdown-checker will be installed in Whonix by default. Dependency of whonixcheck.

https://github.com/Whonix/Whonix/commit/47d9bdde4f9985aa8b29d64c2bd81f17addf18b6

Available in stable-proposed-updates and testers repository.

1 Like