[HOME] [DOWNLOAD] [DOCS] [BLOG] [SUPPORT] [TIPS] [ISSUES] [Priority Support]

[Help Welcome] KVM Development - staying the course


#1

Congratulations Patrick on these new and exciting new developments for Whonix :slight_smile: Looks like I missed quite alot. I want to continue tackling the main blockers for Whonix KVM support. Let me know how I can help.


#2

Hi HulaHoop! Welcome back!

Summary of current state:
https://www.whonix.org/blog/kvm-development-progress/


#3

The most critical issue I remember was the clock setting. IIRC there were two different hings we aimed to accomplish, 1) Disable kvmclock 2) Set the timers used with a random offset ? The first is the most critical.

I found this thread about a libvirt bug closed in 2012, where they could not disable kvmclock from the libvirt xml files:
https://bugzilla.redhat.com/show_bug.cgi?id=783921

Examples of the commands used gives us a clue on what to experiment with to do this. I’ll need to lookup how to use libvirt again.

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Administration_Guide/sect-Virtualization-Tips_and_tricks-Libvirt_Managed_Timers.html


#4

Blockers (highest priority, making this unfit for release, unfit for recommending this to wider use):

Non-blockers:


#5

I believe I managed to solve this. The comment from the thread mentioned in my last post has the answer:

https://bugzilla.redhat.com/show_bug.cgi?id=783921#c6

The command to sniff out kvmclock is different from the one you recommended:

ps -ef |grep kvm

I edited the configuration to have no other timers but the kvmclock one set to not present. Its identical to how that person posted. Using grep after editing shows the absence of kvmclock as a device in the vm, while this command:

ls /sys/devices/system/clocksource/clocksource0/current_clocksource

still gives the response as before:

/sys/devices/system/clocksource/clocksource0/current_clocksource

N.B.
the timer is set to UTC by default so I don’t think there is anything to be changed there.


#6

/sys/devices/system/clocksource/clocksource0/current_clocksource will always exist. It’s content matters. You can check it using.


#7
root@host:/home/user# cat /sys/devices/system/clocksource/clocksource0/current_clocksource tsc

#8

Great. So this is solved. Whonixcheck would report if it was not.

When you run.

it will show, that it does not detect kvmclock.

I’ll fix the other todo item. Wasn’t about UTC. But about.

How to use -rtc clock=vm ?

#9

Besides documenting how the user should manually configure these parameters on the host, I think its much more practical and accessible to the common user to just import an xml configuration file through virsh, that file would be bundled with the images in the tar archives.


#10

Please remind me what we were trying to achieve with clock=vm, how critical is this?

After I’m done with timers, I’ll try and make virtio_blk work for the Debian guests.


#11

This is a very welcome idea.

I think it would be best, if that xml file was created from source, i.e. since xml is not a file format for humans created by humans, if it was created with the appropriate command line tools. Such as that xml file for VirtualBox is created using the VBoxManage tool.

The virsh is developed by a third party, libvirt. (Not that this must be a matter.)

Does KVM have a native command line tool for creating these xml files?

I fixed the remaining blocker todo items.

and


#12

I’d say it’s a blocker (updated todo) because KVM manual says, that clock=vm isolated the guest’s clock from the host’s clock.


#13

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Administration_Guide/sect-Virtualization-Tips_and_tricks-Libvirt_Managed_Timers.html

The link gives conflicting info, maybe you can make sense of it:

kvmclock KVM clock - recommended clock source for KVM guest virtual machines. KVM pvclock, or kvm-clock lets guest virtual machines read the host physical machines wall clock time.

Since we disabled that, this is no longer an issue, however the output for the clocksource implied we are using a tsc timer even though I left nothing listed in the xml file besides kvmclock as disabled.

There are attributes for timers that force it to track guest time or host time:

The track attribute specifies what is tracked by the timer. Only valid for a name value of platform or rtc.

Table 10.3. track attribute values
Value Description
boot Corresponds to old host physical machine option, this is an unsupported tracking option.
guest RTC always tracks guest virtual machine time.
wall RTC always tracks host time.

Since we use tsc as a timer, it doesn’t have a setting for time tracking. If you think we should use rtc instead because it has the option to specifically track guest time instead, this means that we have to put an explicit setting in the config file, probably something like this:

I don’t know how to verify that time is isolated as it is currently. Any ideas?


Please don’t forget to add the links I posted before for disabling kvmclock to the wiki, just in case we need them for future reference.

Edit by Patrick:
fixed quote


#14
Since we disabled that, this is no longer an issue, however the output for the clocksource implied we are using a tsc timer even though I left nothing listed in the xml file besides kvmclock as disabled.
KVM defaults (tsc vs kvmclock) can be distro specific. We should explicitly set it to tsc for better security on various systems.

On my host system and in my VMs, the default (never changed this) is tsc. I guess that is a good reason to keep KVM VMs also in tsc.

I don't know how to verify that time is isolated as it is currently. Any ideas?

Deactivate Whonix specific timesync.

sudo chmod -x /etc/init.d/sdwdate sudo chmod -x /etc/init.d/bootclockrandomization

Power off virtual machine.

Compare host time with VM time.

Open a terminal and type “date” to get the current time. (Graphical clocks may lie to you about seconds due to bugs in these.)

Then do something else (do something in another VM, read a book, get some runts, whatever so time passes). Come back in an hour. Check if anything changed. (Any new delays.)

Then slew the host clock a few seconds forward or backward. See if this has any effect on the VM. (It should not.) Then do something else. Come back in an hour. Check if anything changed. The host/VM time difference should not be changed.

Then slew the VM clock a few seconds forward or backward. See if this has any effect on the host. (It should not.) Then do something else. Come back in an hour. Check if anything changed. The host/VM time difference should not be changed.

When host and VM clock are independent, everything is fine.

Please don't forget to add the links I posted before for disabling kvmclock to the wiki, just in case we need them for future reference.
Feel free to add anything you wish to that page.

#15

Is using shared folders with KVM as simple as
http://www.linux-kvm.org/page/9p_virtio
?

If yes, I would be happy to automate the guest part… We’re currently discussing file transfer between host and VM at the moment anyway (https://github.com/Whonix/Whonix/issues/131).


#16
The virsh is developed by a third party, libvirt. (Not that this must be a matter.)

Does KVM have a native command line tool for creating these xml files?

Unfortunately KVM itself doesn’t. The concept of xml domain configuration is expedited as a function of virsh.

Is using shared folders with KVM as simple as http://www.linux-kvm.org/page/9p_virtio ?

If yes, I would be happy to automate the guest part… We’re currently discussing file transfer between host and VM at the moment anyway (https://github.com/Whonix/Whonix/issues/131).

Yes its that simple, however, SELinux will get in the way in folder sharing for some Linux hosts. Also the safest way to share folders is to have the 9p filesystem mounted in ‘Mapped’ mode.


#17

I am not sure I am doing this right or maybe I am using completely different commands than those that do what we want. The track=‘guest’ attribute doesn’t seem to do anything as a simple time change on the host when the guest is off, pushes guest time 2 hours forward. It turns out clock=vm is a direct qemu-kvm command and has nothing whatsoever to do with virsh. I am not familiar with using qemu-kvm directly to start whonix with all the settings I have applied to it from the GUI. I am sure that this could be scripted somehow maybe?

https://doc.opensuse.org/products/draft/SLES/SLES-kvm_sd_draft/cha.qemu.running.html#cha.qemu.running.gen_opts.rtc

I’ve linked to this before in the dev wiki, but its useful once more: The section for this is: 13.2.3. Guest Real-time Clock

If you need to isolate the VM Guest clock from the host one, specify clock=vm instead of the default clock=host.

You can also specify a ‘starting point’ for VM Guest clock with the base option:

qemu-kvm […] -rtc clock=vm,base=2010-12-03T01:02:00


#18

If you wish to use freenode irc anonymously, I know this can be quite difficult. Because initial account creation can not be done over Tor. In past I used a post-Tor VPN for this. Nevermind. If you need a freenode irc account so you can connect anonymously, I am happy to create one for you.

It turns out clock=vm is a direct qemu-kvm command and has nothing whatsoever to do with virsh. I am not familiar with using qemu-kvm directly to start whonix with all the settings I have applied to it from the GUI.
So this means, to start KVM with this setting, command line must be used? There is no way to set a setting in some config file? Can you ask please on the KVM mailing list please if this is indeed the case?
I am sure that this could be scripted somehow maybe?

As last resort, yes, we can do some long command (Ex. kvm --option a … --option b), then put that all in a script so a user only has to start ./whonix_kvm or press a shortcut. This is easy and I am happy to implement this. Since this would still be very cumbersome and complicate things a lot (cloning VMs and starting VMs with other names would be more difficult), it would be much better if we could avoid this.


#19

I sent an email to the kvm mailinglist, lets wait and see how this goes. If you want me to post what I sent here, feel free to say so.

Added link:
http://article.gmane.org/gmane.comp.emulators.kvm.devel/119996


#20

I guess for reference it would be best to post a link here. (To their mailing list archive.)