[Help Welcome] KVM Development - staying the course

KVM
494

Please do as you see fit.
If the older one doesn’t come up anymore, it could even be completely removed.
If users using older systems still run into it, might be useful to keep the error message inside the text.

495

I stand corrected though in my defense, the last time I checked years ago when 4.X debuted, they implied that they won’t make exceptions for Vt-d-less hardware and reading the hardware reqs seems to imply this by listing this feature as a min req.

1 Like
496

Please kindly subscribe here:

497

Yes, the minimum system requirements implies this is a hard requirement. Created a Qubes documentation bug report for it just now:

1 Like
498

IOMMU (VT-d) was a soft requirement until Qubes R4.0 but is a hard requirement since Qubes R4.1 as per:
https://github.com/QubesOS/qubes-issues/issues/7581#issuecomment-1160426503

Another ticket to clear up confusion created just now:

1 Like
499
500
501

I think we can go ahead and rip out the qxl dependency in whonix and KS as it is now obsolete and we no longer use the graphics device in question. @Patrick

1 Like
502

For reference only:

503
504
1 Like
505
1 Like
506

This change is now in the testers repository.

1 Like
507

Discussing this in 2 forums at the same time makes it a bit weird to keep everything updated. Best to keep discussions in the original, specialized forum thread only and only post a link here for reference.

1 Like
508

@HulaHoop
I see you’ve been doing Whonix KVM for a long time, but I also see that the builds have stopped.

  • what is the state of the KVM development?
    • do you plan to continue development? If so, any ETA?
  • how much time do you take per month to maintain KVM?
    • what takes most of your time during maintenance?
    • what are repetitive but necessary tasks that have to be done and takes a long time?
  • anything I didn’t ask you’d like to add?

I don’t know if I can maintain, my experience with KVM is not as broad and my time might also be short, but I like that there is a KVM option alternative for Virtualbox, while Qubes is not an alternative for everybody.

1 Like
509

Didn’t drop the ball yet, just quite busy for now. If I abdicate my post it will be announced beforehand.

Absolutely.

Stable these days. I look at new features under design and make a list of the changes/features I want to add when the new libvirt version included in stable next comes out.

Troubleshooting support topics takes the most time nowadays. Any help with this is always welcome from other KVM power users.

Builds are the necessary and time intensive task you mention, but they are straight forward. Researching improved options in encryption and security software is also something that benefits Whonix in general and not just KVM which I have done. Looking out for security CVEs in Tor, openssl, apt or KVM are very important as those warrant emergency builds.

2 Likes
510
511

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:

512

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

513

[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:

  1. The computer that runs Whonix. Does not have its own network connection. (Whonix)
  2. Is connected to a physically isolated other computer through a LAN cable. (Proxy)
  3. 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.)