Also, is Whonix vulnerable beause it hasn’t installed CPU microcode updates to address speculative attacks? That is, the package update is only available from Debian non-free repo?
See here: Debian -- Security Information -- DSA-4279-1 linux
From memory, I only saw this update happen in Qubes Debian 9 TemplateVM and not Whonix-14 ones.
https://packages.debian.org/stretch/intel-microcode
https://packages.debian.org/stretch/amd64-microcode
Installing them by default would require Debian nonfree repository and Whonix images non-free.
Are these even required / effective inside VMs?
To test:
With and without microcode installed.
https://packages.debian.org/stretch/iucode-tool
sudo iucode-tool -S
/usr/sbin/iucode-tool: system has processor(s) with signature
//cc @HulaHoop
Related:
Its really sad or fun to see how intel manipulating our heads to force their evil code:
Electronic Micro-Satanic Scenario:
The Case Mission: Force Closed-Source Programs for Freedom programming Seekers
Problem: No one like to be hacked/spied on from anyone by forcing him to do that.
Solution: Best manipulation is to be legal, And by that it means = letting the user using the evil code by their will.
Problem: Intel is an evil company which makes and sell vulnerabilities with US government. So no one would like to use their code inside a freedom society. (Though alot of hardware used by freedom society made by Intel)
Solution: Reveal a horrible vulnerability which the freedom society is using and make the solution for it = everyone going to panic to use that solution to fix this vulnerability which take their freedom away.
Problem: But the code of this patch for that vulnerability is closed source as well, so how will anyone make sure that there is no even a vulnerability inside the installed patch? (except if he has the code of that patch or hes a god in knowledge of everything)
Solution: Name that as a “Security Patch” and everyone gonna install it. (regardless if its an evil closed source program = virus or not)
Mission Accomplished.
Guests have no way to alter the microcode, only the host so having it installed for virtualized Whonix has no effect. A Whonix guest needs CPU passthrough (non-QEMU emulated model) access to host instructions for the kernel mitigations to take effect.
The microcode packages are useful when Whonix runs as a physical build however. This inlcudes ARM.
Thanks. We’ll note that somewhere in wiki.
So also affects Raspberry Pi development @Algernon & would require this package installation to be safe
Do you mean without CPU passthrough Qubes and VirtualBox are hosed? Are you sure about that? Isn’t that up to the hypervisor?
RPI is neither intel nor amd.
But some of the ARM processors are also affected, sadly the faster and hence more useful ones seem to be more affected. The one in the RPI 3 (A53 processor), however, is not.
See here for more information: Speculative Processor Vulnerability
I can try to include the microcode packages for intel and amd in the whonix-gateway-cli package but I don’t know if they can be installed at the same time. Otherwise the enduser would need to manually install them. Also you could not use the package anymore as Depends for the rpi package since the intel/amd microcode packages are obviously not available for ARM.
I second that request. I think the settings for KVM were changed recently to enable some mitigations but I don’t know what influence the chosen CPU model has.
I can see that everyone thinking its a real patch without being another vulnerability.
so i request to stop thinking about implementing the solution rather than thinking about the solution itself , answer the very simple question:
how can anyone prove that this is fixing patch without being by itself another vulnerability that might be discovered later?
and i have made my philosophic view through the story that i mentioned above.
you will only know this in case if you have/know the code otherwise we are bullshitting around.
IIRC when we tested CPU for identifier leaks, only KVM could optionally mask out flags. Xen and VBox just passed through all/most of host processor instructions. To confirm this just cat the cpuinfo on Dom0 and compare with the output in DomU.
Is there a non-complex way of excluding/choosing dependencies based on the chosen hardware platform?
Here is the post behind my recent config change:
https://www.berrange.com/posts/2018/06/29/cpu-model-configuration-for-qemu-kvm-on-x86-hosts/
Probably yes, it looks like Depends can be made architecture specific.
Yeah, the relevant part is actually in one of the comments:
Tim said at 11:14 am on July 9th, 2018:
Is it possible to use default models and include the mitigations for the different vulnerabilities? Something like kvm64 + spec-ctrl …
Daniel Berrange said at 3:06 pm on July 27th, 2018:
Yes, it is possible to use kvm64,+spec-ctrl but I won’t not really advise doing that for a number of reasons.
First as mentioned kvm64 is an ancient CPU model, pretty much awful as qemu64. By using it you are intentionally throwing away performance that your host CPUs have. eg your host CPU almost certainly has ‘aes’ support but with kvm64 your guest won’t see it, so it will do pure software AES and so needlessly burn CPU cycles for TLS connections.
Second, guest kernels look at the CPU family to determine whether they’re running on a CPU that does speculation and thus needs mitigation. If they 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.
From reading the last paragraph it looks like setting a CPU model could help depending on the model. I’m also not sure if anyone did actually do some real research on this. Maybe using the spectre-meltdown-check script + using different cpu models + the mitigations in the xml file could give some answers
What about the CPU model? Afaik XEN should be capable of changing this
I can see that everyone thinking its a real patch without being another vulnerability.
so i request to stop thinking about implementing the solution rather than thinking about the solution itself , answer the very simple question:
how can anyone prove that this is fixing patch without being by itself another vulnerability that might be discovered later?
That’s a too high standard: this is never possible even for the most
exemplary Libre Software projects.
and i have made my philosophic view through the story that i mentioned above.
you will only know this in case if you have/know the code otherwise we are bullshitting around.
Well, without microcode package:
With microcode package:
Picking a default specific CPU model that approximates the host’s is not a good idea because I cannot predict what model the user is running and if they are using Intel or AMD. Its more likely Xen is capable of changing these settings anyhow because of migration compatibility.
As far I know Qubes and VirtualBox are not using CPU passthrough, neither it’s easy to enable it.
A Whonix guest needs CPU passthrough (non-QEMU emulated model) access to host instructions for the kernel mitigations to take effect.
This could be understood as:
Is any of that what you meant? References?
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.
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.