I was able to run Whonix on KVM without any errors by making the following changes to the installation procedures at Whonix ™ for KVM :
I didn’t add the line “deb Index of /debian wheezy-backports main” to /etc/apt/sources.list
I used the command “sudo apt-get install qemu-kvm libvirt-bin virt-manager” instead of “sudo apt-get install -t wheezy-backports qemu-kvm libvirt-bin virt-manager”
I edited the xml files to remove the “MemoryBacking” tags and the “hugepagetables” line between them.
After running Whonix, I also tested that the rng was correctly installed by creating a key pair in KGPG.
I notice that it seems slower than Whonix under Virtualbox but I can’t say to what extent that is due to either KVM or due to the absence of the hugepagetables setting.
I would like to ask:
What are the backports supposed to do?
What is the significance of leaving out the hugepagetables setting?
After running Whonix, I also tested that the rng was correctly installed by creating a key pair in KGPG.
This is not a valid test. Whonix installs https://packages.debian.org/wheezy/haveged by default. Jacob Appelbaum recommended haveged to Tails if I remember right, speeds up generating randomness. [+ May improve random quality, but I'd rather not go into that difficult topic.]
Nevertheless, with KVM’s rng device, the kernel has no good source of original randomness in the first place that haveged could sanely build upon. Without KVM’s rng device, it could fast but weak entropy.
I have now installed the latest Debian Testing (Jessie) for the host OS and installed KVM according to the instructions at Whonix ™ for KVM
I get exactly the same collection of errors as described in a message in another thread (Whonix Forum) where I had Debian Stable (Wheezy) for the host OS and wheezy-backports as the repo for the installation of KVM.
Would it be worthwhile to compile and install the latest KVM source code or is that unlikely to be of any use?
My waiting probably only a few weeks for the latest “rc” of the source code to be packaged into the backports repo. That estimate is derived by looking at Releases · qemu/qemu · GitHub and noting that the current qemu-kvm backports version (2.1.2) is the second one from the top, and that they come out, on average, about a month apart.
Creating a deb package myself, for its self-instructional value.
I made good progress until I encountered the dependencies, of which there seem to be an infinite number. The difficulty is compounded by the fact that the error messages produced by “dpkg-depcheck -d ./configure” are hardly ever specific as to the name of the package that is required, so each iteration involves searching online and some guesswork.
Looks like I’ve reached the limit of my competence as a 4-hour developer (sounds like a great title for a book). I’ll have to let this rest, since it’s a bigger task than I’d anticipated. I’ll just use virtualbox for now and revisit kvm in a few months.
Good news! Whonix now runs on KVM if you firstly edit the xml files to remove the “MemoryBacking” tags and the “hugepagetables” line between them. That is the only change necessary thanks to QEMU-KVM updates that came down today.
To upgrade KVM, if you have a previous installation:
Run “sudo apt-get update && sudo apt-get dist-upgrade”
Run “sudo apt-get remove qemu-kvm libvirt-bin virt-manager”
Then re-install qemu-kvm, libvirt-bin, and virt-manager according to the version of your host OS, as described in Whonix ™ for KVM
I should add (after seeing Hulahoop’s post here: Whonix Forum) that I consider it good news that the latest KVM runs Whonix with only a single modification of the xml files, because that means there is, apparently, just one bug left to fix. But I have no intention to use Whonix on KVM other than for testing until it imports and runs without such hacking.
I’ve been looking for a possible cause of this problem, of Whonix not starting because of the hugpagetables entry in the xml files.
I found this, as well as a few other, similar links:
It seems that the Apparmor policy for huge pages sets the file under the mount point to read rather than to read&write. It is a bug in the way that Apparmor sets the policy, although there are hacks that will bypass it. I could not find any mention of whether the bug has been recognized and addressed by the apparmor maintainers. A search at the apparmor bugs page, bugs.launchpad.net/apparmor does not find any relevant result.
Am I looking in the right place and it is a bug that hasn’t been reported to the developers? Hard to believe but maybe they don’t know about it.
Dennis you will have to rule out that hugepagetables is supported in your version of KVM. The best way to get to the bottom of this is to ask on the libvirt mailing list here: libvir-list Info Page
They also handle the creation of Mandatory Access Control rules that isolates KVM for Apparmor and SELinux. They would be the best people to report bugs to about the Apparmor rules so they can fix it.
With similar reports from whonixfaithful, another Debian user, I think your problem is reproducible.
Please post a link to your mailinglist message if you decide to post to them.
Is this a general problem or one that only I am having? The silence that I’ve received has led me to, perhaps incorrectly, assume that it was a general problem.
Whatever the cause, it is not the same as Whonixfaithful’s problem here: Whonix Forum. That’s because he is running apparmor on his host OS and that’s where his problem is and that’s where he fixed it. On the other hand, I am not running apparmor on my host OS, (“aa-status” gives “command not found”) which is a clean install of Debian Jessie. It is possible that the apparmor INSIDE my Whonix-Gateway is the cause of the Whonix-Gateway not starting but since I don’t have access to it I can’t do the diagnostics or examine its logs as recommended in the other discussion mentioned above.
Actually, I’m wondering how apparmor inside the Whonix-Gateway could have any relevance at all if the image isn’t even booting.
Is there a way to start Whonix-Gateway with its apparmor disabled? In the “Virtual Machine Details”, “Boot Options”, there is provision for “Direct Kernel Boot” where one might enter “apparmor=0” in “kernel args” to disable apparmor, but the paths to the kernel and the initrd are required, and it won’t work if I put in the path to the qcow2 file.
Unlikely. You should at least see the virtual BIOS (no AppArmor there) and the initial boot. If AppArmor was badly broken, it would boot up and then stop, or endlessly reboot.
Is there a way to start Whonix-Gateway with its apparmor disabled?
Recovery mode has apparmor disabled.
Also undoing the effects of the grub-enable-apparmor package. Easy for debugging purposes by purging it (sudo apt-get purge grub-enable-apparmor). Not so easy for production builds, see Debian Packages - Whonix. For production use, switch the apparmor setting in /etc/default/grub.
Which is non-ideal. Perhaps we should try to find another KVM maintainer that uses Debian? You as Fedora(?) host user + someone else?
If you feel its necessary I’m fine with it. Although its not really enough that they use Debian, they would have to be knowledgeable about Apparmor rules too if thats the case.
Its most likely a problem with hugepagetables not being supported by KVM on Debian yet. I am willing to keep an updated list of settings that need to be removed for Whonix on Debian to work. B