Some issues such as the following I don’t see to ever get resolved unless contributed. Quote Dev/VirtualBox - Whonix chapter Why use VirtualBox over KVM? in Whonix wiki
KVM disadvantages:
- Virtual network interfaces by KVM: Are visible on the host using tools such as “
sudo ifconfig”.
- KVM: This complicates leak tests because tshark / wireshark on the host can see connections between Whonix-Workstation ™ and Whonix-Gateway ™.
- KVM: Therefore also leak-testing using corridor on the host failed
.
- KVM: A useful host firewall and/or VPN fail closed mechanism (even if Freedom Software) can break Whonix-Workstation KVM network connectivity. References:
- KVM: host software such as for example NordVPN client kill-switch can break Whonix-Workstation KVM network connectivity.
- https://forums.whonix.org/t/failure-to-connect-when-vpn-on-host/3133[](https://web.archive.org/web/https://forums.whonix.org/t/failure-to-connect-when-vpn-on-host/3133)
- KVM: Undocumented how to use a host VPN (and therefore failing
](https://forums.whonix.org/t/failure-to-connect-when-vpn-on-host/3133%5B!%5B%5D(https://www.whonix.org/w/images/7/73/Internet_Archive_logo.png)){kind=link}
KVM disadvantages:
- Virtual network interfaces by KVM: Are visible on the host using tools such as “
sudo ifconfig”.
- KVM: This complicates leak tests because tshark / wireshark on the host can see connections between Whonix-Workstation ™ and Whonix-Gateway ™.
This can be taken into consideration and has been accounted for in leak tests in the past therefore this conclusion does not follow and sounds FUDish:
- Therefore Whonix VirtualBox has a higher leak-proofness then Whonix KVM.
The rest of the complaints on that page about corridor and host VPN killswitch incompatibility are not inherent limitations but need someone knowledgeable and able to troubleshoot them to work. They are also unrelated to KVM’s leaktest security
[A] Leak test complication:
How do you exclude Whonix-Workstation to Whonix-Gateway internal traffic from tcpdump, tshark, wireshark? That should be documented.
[B] Why host firewall / VPN killswitch matters:
If a host firewall or host VPN can break Whonix-Gateway connectivity that would not necessarily be a leak risk indicator. But Whonix-Workstation should be conceptually encapsulated by Whonix-Gateway. A host firewall or host VPNs shouldn’t break Whonix-Workstation connectivity only while Whonix-Gateway still has connectivity.
Whonix-Workstation and Whonix-Gateway KVM are connected by virtual network interfaces (and iptables?). A virtual LAN cable. If a host firewall or host VPN can disrupt that virtual LAN cable, unplug it or worse connect the Whonix-Workstation virtual LAN cable to the VPNs virtual network adapter, then that would result in a leak.
So it would be much better if internal network interface wouldn’t be visible on the host operating system but I don’t know if that is possible with KVM.
[C] corridor:
corridor is an alternative leak test based on a really cool idea to say connections to Tor relays (or bridges) are permitted but everything else is considered a potential leak. Having any port of Whonix leak tested with corridor is an advantage. Not having done this is a disadvantage.
Most of these Whonix KVM apply only happen when running the leak test on the same computer as Whonix is currently running. A different setup:
- The computer that runs Whonix. Does not have its own network connection. (Whonix)
- Is connected to a physically isolated other computer through a LAN cable. (Proxy)
- Leak tests are run on the proxy.
[A] Would be less of an issue. But there’s a new issue. Then the traffic generated by the host operating system needs to be fully disabled for everything except the running Whonix VMs (NTP, updates, DHCP). Otherwise the leak tests would show false-positives.
[B] Would still be an issue but at least the leak tests are easier.
[C] Corridor should run fine here. (But also host traffic for all but Whonix VMs needs to be disabled.)
Instructions on how to adjust amount of RAM for KVM is missing:
got reply here: Enable extended L2, reduce cluster size by HulaHoop0 · Pull Request #1 · adrelanos/Whonix · GitHub
It is recommended to move the image files instead of copying them.
Why?
Copying them without extra parameters causes them to lose their sparse
property, giving the user a nasty surprise.
Then this sentence, recommendation should be rewritten. There’s no
reason to not copy the files if doing it the proper way preserving
--sparse-always.
This page seems centered around VBox for all aspects. It would be too much to duplicate for all KVM related instructions. Anyhow, the user base for KVM is already much more knowledgeable that such instructions would be overkill. Not out of elitism, but the install process itself is unfortunately a major filter for those who wouldn’t know how to set RAM to begin with.
OK corrected
That wiki page has been improved just now. It is now using a tab controller which makes it easy to switch the virtualizer which shows/hides the other virtualizer.
Shouldn’t be duplicated but would be good to shorten wiki/KVM by moving into the proper specialized wiki pages.
@HulaHoop is this still true? meaning if LVM used we can rely on it without spice? does this as well improve other hypervisors like Virtualbox?