Yes the emulator tag can be eliminated in its entirety, as its recreated according to the domain type that is set. the domain tag has to have a specific value and can not be omitted, because it causes the import process to fail.
For the clock settings would you like the clocks to drift on purpose and not be accurate, for example because of missed ticks ?
Between qemu and kvm there isnât much difference. Or maybe there is, because KVM is designed to rely on VHost kernel mode only drivers for paravirtualization of devices, and nothing involving qemu at that point.
EDIT:
qemu works with these settings, only needing a tag change. Pure qemu is very slow obviously but it works.
Iâll see if libvirt automatically sees hardware architecture, Running a compiled Whonix ARM version for debugging in the future may be useful
EDIT 2:
Hardware architecture and chipset options could be safely eliminated from within the tag.
In this specific example, only the domain tag that needs needs changing however the differences grow when one looks at LXC then Xen etc.
The question is should we be discouraging the running of Whonix on less secure setups like containers and Xen? Yes Xen is insecure and i will explain why if you want. Its been referenced in that security report I referenced before.
Note import fails if it detects a domain with the exact same name already present. We will have to switch the generic file naming back to what it was with the version numbers being present again. I have an idea how we can handle it now.
While libvirt doesnât work with relative paths, bash scripts I know can handle this. This elegantly solves the problem. Using sed we can alter the xml to reflect changes desired by the user by adding containment platform name and for exmaple: kvm, qemu etc to the disk image filename , the vml âdomainâ name and also alter the name in the path string inside the xml.
The proposal for the script structure in plain language:
First we rollback the change for file naming and allow the version number to be generated. This is important becuase using one static domain name and disk image file name is problematic for the import process:
0. The script would recognize the filenames in the format that was used previously roughly: whonix_gateway_$version
1. Script asks user for choice of containment platform
2. sed is then used to apply the relevant changes to xml to reflect that
2a. It would change the generic value name such as whonix_gateway thats initially used in the config file and apply the new filedisk name to the path, the vm 'domain' name and finally rename the actual image on disk to use that name : formatted like: whonix_gateway_$version_$containment+[alternative arch if selected for qemu].
3. Detect output from virsh if there is already an existing vm 'domain' with the same name (and hence disk file with same name too) and alert the user and exit.
4. If import successful, copy disk image only to the /var/lib/libvirt/images directory. Done!
(no need to copy the xml after import as libvirt stores it wherever it wishes)
The goal is to have one xml file, per vm provided, thatâs edited according to main user decisions and have the disk file and image reflect that.
Please do.
the domain tag has to have a specific value and can not be omitted, because it causes the import process to fail.Ok, when someone requests qemu support, the installer script can add an option and patch the xml.
For the clock settings would you like the clocks to drift on purpose and not be accurate, for example because of missed ticks ?
Yes.
Hardware architecture and chipset options could be safely eliminated from within the tag.Great, please do so.
In this specific example, only the domain tag that needs needs changing however the differences grow when one looks at LXC then Xen etc.No problem. We can do separate files for them - if there is someone sufficiently interested and helping with this as you are doing with KVM.
The question is should we be discouraging the running of Whonix on less secure setups like containers and Xen?We are already doing this. whonixcheck warns against virtualizers, that do not have a Whonix maintainer who developed/tested/maintains them. The warning text is implemented here: https://github.com/Whonix/whonixcheck/blob/master/usr/lib/whonixcheck/check_virtualizer#L58
Yes Xen is insecure and i will explain why if you want. Its been referenced in that security report I referenced before.If it concerns Qubes OS, then I would be interested. Since there is Qubes OS, I am not motivated to look into the Xen.
Sounds good. I ask about some details when I get to it, probably soon.
Ok, when someone requests qemu support, the installer script can add an option and patch the xml.
Great. For the architecture choice though it would need to insert the arch=âarmâ option under the tag. As of now I removed it as its strictly not necessary.
Good question. I am not sure yet. This setting might be fingerprintable. I guess "catchup" is the default, makes sense, and using default is probably best we can do here.
Ok left it as it is.
I am relinking to this post so the import commands for the network donât get buried, they are needed to get it imported and then enabled: Whonix Forum
EDIT
I noticed that we could he a subsection in the to force domain overwriting (besides file overwirting) by the user if its intentional.
virsh gives error that it already exists overwrite? [y] then remove domain followed by reimport. [n] exit.
Same for virtual internal net, except there is a command to stop it first then remove it.
Arm importing requires qemu arm to be installed. So the user should get a prompt to install that package and try again.
I started implementing the libvirt import script. Can be found here:
https://github.com/Whonix/Whonix/blob/master/libvirt/whonix_libvirt_import
Still non-functional (a few functions are tested, though). We can use that draft as base for discussion and finishing implementation. There will be some questions.
I copied those into the script, so they donât get lost. (Yet have to adjust the paths.)
I noticed that we could he a subsection in the to force domain overwriting (besides file overwirting) by the user if its intentional.
virsh gives error that it already exists overwrite? [y] then remove domain followed by reimport. [n] exit. Same for virtual internal net, except there is a command to stop it first then remove it.I think it's best if the script has both, an interactive mode [terminal] and a command line mode. Perhaps even an environment variables mode (reading settings from environment variables). Not difficult to implement, if virsh provides the necessary command line tools. Maybe later even graphical mode, but that later, could be difficult (because the script must work with minimal dependencies, unless we tell people to "sudo apt-get install kvm zenity" beforehand.
Arm importing requires qemu arm to be installed. So the user should get a prompt to install that package and try again.Let's deal with arm later. We don't have arm builds for now anyway. I don't know how difficult they would be to create and for now we have no such feature requests.
To detect if such a domain is already existing, the script currently uses something like:
If exit code is non-zero, we can just go ahead importing it. Easy.
And if exit code is 0, it already exists. Then could ask the user if she wanted to delete that VM. And if yes is chosen or if --force-override was used, then we could use this command.
undefine domain-id [--managed-save] [--snapshots-metadata] [ {--storage
volumes | --remove-all-storage} --wipe-storage]
Should we wipe all, i.e. power off, delete domain and image then?
The simpler way would be just to tell the user, that she should consider renaming/removing the VM manually and exit 1.
I am still not sure this script should support importing both, Whonix-Gateway and Whonix-Workstation when both images and the same script are in one folder. Not autodetecting that situation and to require the user to use two import scripts from two folders (extracted from two archives) is certainly easier and faster to implement. What do you think?
Why use Whonix_Gateway and Whonix_Workstation instead of Whonix-Gateway and Whonix-Workstation? Avoiding conflicts with eventually existing VBox VMâs? (âvirsh listâ interestingly also shows VBox VMs.)
Improved the script some more. Implemented most functions. Still untested.
Check it out:
https://github.com/Whonix/Whonix/blob/master/libvirt/whonix_libvirt_import
For now, only one xml / image is supported in same folder.
#2a. It would change the generic value name such as whonix_gateway thats initially used in the config file #and apply the new filedisk name to the path, the vm 'domain' name and finally rename the actual image on disk to use that name : #formatted like: whonix_gateway_$version_$containment+[alternative arch if selected for qemu].What advantages does that bring? Complicates the script and I don't understand yet for what it's good for. Is this really important / necessary?
I think it's best if the script has both, an interactive mode [terminal] and a command line mode. Perhaps even an environment variables mode (reading settings from environment variables). Not difficult to implement, if virsh provides the necessary command line tools. Maybe later even graphical mode, but that later, could be difficult (because the script must work with minimal dependencies, unless we tell people to "sudo apt-get install kvm zenity" beforehand.
Yes agreed, both terminal and commandline give useful options. I will check if virsh does implement environment variables and report back. A GUI mode is definitely helpful to add for our main demographic. I have Zenity installed by default here but I donât if thats the same for most distros and/or debian. If you decide to rely on a single dependency for the gui thats installed everywhere by default then it would be better.
The simpler way would be just to tell the user, that she should consider renaming/removing the VM manually and exit 1.
Yes. Just notifying them should be enough as its impossible to know what they want to do to deal with this.
I am still not sure this script should support importing both, Whonix-Gateway and Whonix-Workstation when both images and the same script are in one folder. Not autodetecting that situation and to require the user to use two import scripts from two folders (extracted from two archives) is certainly easier and faster to implement. What do you think?
I believe that 2 scripts, one for each image is a better modular design solution. But the setting up information for the isolated whonix_network.xml is to be included and triggered from the whonix gateway script.
If the script detects an already existing virtual network from a past install, it should exit silently.
Concerning the virtual network there is a problem :
I believe its very important to put a security warning at the beginning of the process in the script to warn people to shutdown any currently running Whonix vms as they will be using this same internal network.
An adversary who has compromised the older running whonix workstation could attempt to attack the newly added vms that are programmed to used this same internal network.
Why use Whonix_Gateway and Whonix_Workstation instead of Whonix-Gateway and Whonix-Workstation? Avoiding conflicts with eventually existing VBox VM's? ("virsh list" interestingly also shows VBox VMs.)
What advantages does that bring? Complicates the script and I don't understand yet for what it's good for. Is this really important / necessary?
Yes libvirt auto-detects and interacts with vms that belong to all supported hypervisors. In this situation its best to change the name then to the other format. With that said I think the suggested renaming mechanism to accomodate hypervisor type and architecture version (just the naming and not the actual changes for the architecture) is important in the case of libvirt to allow people to tell machines apart. For example they may already have a kvm machine and also want to install the qemu version of the same number. Wihtout implementing this, the kvm machine would be wrongly detected as a duplicate of the different qemu machine that a user wants to introduce. Its much more helpful considering the sheer amount of containment types libvirt supports.
Why is it
And not
?
(We change it later anyway, but still. I guess keeping the existing naming schema is better.)
Works:
Does not work:
Please tell me a functional version.
This is kinda difficult. Add line "xxx" after line "yyy" isn't the most clean code, doable, but I prefer to avoid it. Could we add the arch field to the xml but leave it empty by default or would that be non-functional?This is kinda difficult. Add line âxxxâ after line âyyyâ isnât the most clean code, doable, but I prefer to avoid it. Could we add the arch field to the xml but leave it empty by default or would that be non-functional?
Best we can do is attempt to auto detect this. Like the start-tor-browser script does. It checks for zenity, kdialog, gxmessage, xmessage and opportunistically uses one of them. There may be very well be situations were none of them is installed by default.
Yes. Just notifying them should be enough as its impossible to know what they want to do to deal with this.Well, not impossible, but needs some time to implement to ask the user on how to proceed.
I believe that 2 scripts, one for each image is a better modular design solution.That's it for now.
But the setting up information for the isolated whonix_network.xml is to be included and triggered from the whonix gateway script.Easy and done. The import script checks if whonix_network.xml in it's own folder, if no, it's skipped.
If the script detects an already existing virtual network from a past install, it should exit silently.You mean skip adding the virtual network then?
This is not implemented yet, but should be.
How can the script check, if the virtual network already exists?
Concerning the virtual network there is a problem : I believe its very important to put a security warning at the beginning of the process in the script to warn people to shutdown any currently running Whonix vms as they will be using this same internal network. An adversary who has compromised the older running whonix workstation could attempt to attack the newly added vms that are programmed to used this same internal network.We have an info text when importing VBox VMs. (https://github.com/Whonix/Whonix/blob/master/build-steps.d/2700_export-vbox-vm#L25) Could you write such a text for KVM? Adding it to the script once written, adding it to the script including a --skip-info switch would be trivial.
Yes libvirt auto-detects and interacts with vms that belong to all supported hypervisors. In this situation its best to change the name then to the other format. With that said I think the suggested renaming mechanism to accomodate hypervisor type and architecture version (just the naming and not the actual changes for the architecture) is important in the case of libvirt to allow people to tell machines apart. For example they may already have a kvm machine and also want to install the qemu version of the same number. Wihtout implementing this, the kvm machine would be wrongly detected as a duplicate of the different qemu machine that a user wants to introduce. Its much more helpful considering the sheer amount of containment types libvirt supports.I hope you're right. Was quite some work, but it's now implemented in the repo (still untested due to open questions raised above).
Weâre now using for image.
${source_domain_name}_${version_number}_${target_domain_type}.${vm_source_image_extension}Example:
Whonix-Gateway_8.3_kvm.qcow2Weâre now using for domain name.
${source_domain_name}_${version_number}_${target_domain_type}Example:
Whonix-Gateway_8.3_kvmMaybe add extension (.qcow2) to domain name as well? No?
I foresee one issue. Someone asking in the forum "In past I could only use qemu, but now I got a new computer and want to use kvm. I got an image named Whonix-Gateway_8.3_qemu.qcow2. Why is qemu hardcoded? WTF? Canât I just use it in kvm? Perhaps we got to live with that.