Yes let’s stick with qcow2.
I pasted the logs on the wiki, but they are mangled badly. Blockquote tag doesn’t preserve their format like whats shown here. poem tag is not recognized at all. Please take a look and tell me what works.
If I was to ask more question on IRC, what would be our priority to know?
I wrapped the irc logs into
. That should do.Most important question is how to add the kvm command line parameters to the config file. As in, how to create a config file for all settings we required without using libvirt. (We discussed few days ago.)
Solved through libvirt xml 
Turns out that adding clock=‘vm’ to the rtc timer in the xml file does it. All that qemu-kvm workaround is not needed I disabled timesync and followed the console steps you listed to verify that there is a separation. I think the reason it didn’t accept the parameter in the past was because I was adding it to another timer or it was just a bug. Please confirm of course.
After the workstation is booted and running no change to host time affects the guest whatsoever. If the guest is shutdown and turned on again it does base its time off the host but at no point is it affected by changes to host clock.
Dev Wiki material:
links about the patches to libvirt that set these features exposed by qemu-kvm. Among them are other useful settings.
-rtc base=localtime,clock=vm,driftfix=slew
libvirt “clock=vm”
https://www.redhat.com/archives/libvirt-users/2013-December/msg00019.html
https://www.redhat.com/archives/libvir-list/2010-March/msg01293.html
https://lists.gnu.org/archive/html/qemu-discuss/2014-02/msg00018.html
The links in this section are a brainstorming of ideas for me on getting offsets on working, has nothing to do with the separate problem thats been solved above:
figuring out random offset:
https://www.redhat.com/archives/libvir-list/2010-March/msg00304.html
https://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Virtualization_Deployment_and_Administration_Guide/sect-Virtualization-Tips_and_tricks-Libvirt_Managed_Timers.html
Unfortunately offsets are enforced at the number one chooses rather than a random figure falling into a range. Besides this, I don’t know if my findings for clock=vm are anything valid, which is disappointing.
I am not surprised. Everyone has to choose it’s own random offset. Ideas:
I don’t understand.
I think its important that everyone has it, so I agree with option 1). Is 3) a way to build this feature? If its a script it could easily be selected for running at startup through a DE’s settings GUI. Unless you have an even more seamless way to make this simpler of course.
I don't understand.
I’m not sure if I’m doing it right. I’ll tell you what I mean. I type the setting and save the xml, but its not there when I open it for editing once again. When I turn on a vm and I change host clock while its running, I see from the terminal that the host date and clock did in fact advance one hour. But the guest doesn’t change in the slightest.
Is this the correct way to check?
N.B. I disabled the timesync as you told me.
If I edit the xml to add clock=‘host’, it too disappears, but the setting has no effect - meaning host time changes still don’t affect guests.
Okay. Can you write a feature request please? Then post it here. I’ll look over it. Then we can post it.
Is 3) a way to build this feature? If its a script it could easily be selected for running at startup through a DE's settings GUI. Unless you have an even more seamless way to make this simpler of course.Depends on how the rest gets implemented. Best would be two .qcow2 images + a settings file + instructions how to get it installed and started? If so "start this extra script every here and now to randomize times" would make this more cumbersome.
I type the setting and save the xml, but its not there when I open it for editing once again.Sounds like these filers are not supposed to be edited by hand? At least not while kvm is running? I guess they get reset by kvm. Your changes may persist when all kvm machines are shut down. Please try that.
When I turn on a vm and I change host clock while its running, I see from the terminal that the host date and clock did in fact advance one hour.But the guest doesn’t change in the slightest. Is this the correct way to check?
If I edit the xml to add clock='host', it too disappears, but the setting has no effect - meaning host time changes still don't affect guests.Probably it was disregarded. As I said earlier in this post. Maybe this works when kvm was shut down, so it doesn't overwrite your manual changes.
Depends on how the rest gets implemented. Best would be two .qcow2 images + a settings file + instructions how to get it installed and started?
Exactly, this is much simpler and what I had in mind. It makes kvm Whonix uniform on all systems it runs on too. Its also the closest to an .ova drop-in replacement as possible. The images with the xml configuration that is imported with the exact optimal settings we decide on.
If so "start this extra script every here and now to randomize times" would make this more cumbersome.
On second thought, yes you are right about this making things needlessly complicated, but if its very important in situations where a hidden service is being sniffed out, then we should include a script for it with optional instructions in the wiki. However I have an alternative last suggestion at making this setting applicable for everyone. How about adding to UTC some offset based on some country’s timezone to solve this? That has the advantage of being something we could set in xml. If you agree I’ll write the feature request based on this instead.
Update:
I decided to ask on #tor about the benefit of the random offset. Its clear that we have different views of the threat model, but I decided to post it anyway for reference.
Hi guys. I'm working on the Whonix project and wanted to know something about clock offsets and insecure time syncing I'll wait when someone can help bancfc: this is a group support environment, just throw your thing out and wait use UTC as default time is the first step @bancfc ok. So far we managed to set kvmclock to not be present and then we isolated the guest clock from the host as to not allow any global adversary to induce a time skew detectable in both environments and? now we are decidding if adding a random time offset upon vm initiation is any useful a vm bases its time on the host clock when started from a cold state is this dangerous in any way? Keep in mind, that no changes to the host clock have an effect on the time inside the vm anymore sync all clock every one hour with local UTC time yes we have a timesync script inside the vm for that it shouldn't be a problem to have the clocks of host and guest in sync, especially if the host clock is in sync with the internet velope: so as long as they don't affect each other its all good? bancfc: you are in the realm of very subtle and unlikely attacks. there should be no need to mess with this, again, especially if the clocks are reasonably in sync with the internet. velope: If we question unlikely attacks we could question the point of Whonix as being overkill, but its designed for extreme situations which *do* exist in the world unfortunately. Velope: Do you think there is no reason for the offset being random, or the whole concept of vm and host clock being isolated? i think it is something that even experienced people wouldn't bother with but if you want to create some small random difference, go ahead and knock yourself out If everyone is synced with insecure ntp are their clocks exactly the same to the T ? just remember that you don't want some consistent, repeatable difference from internet time, which itself could be a fingerprint, or an inaccuracy of more than a few minutes, which could break things in tor ok thanks
Sounds like these filers are not supposed to be edited by hand? At least not while kvm is running? I guess they get reset by kvm. Your changes may persist when all kvm machines are shut down. Please try that.
ok I’ll check.
Edited to add:
Same thing happens with editing while vm shutdown, but the clocks are still separate.
My config file looks like this:
<clock offset='utc'>
<timer name='kvmclock' present ='no'/>
<timer name='rtc' present='yes'/>
<timer name='pit' present='no'/>
<timer name='hpet' present='no'/>
</clock>
I add the clock=‘vm’ part in the middle of the rtc line.
Alright nevermind my last post. I thought all the attack scenarios through and think this is really important. A global adversary has all the time in the world to mount finely tuned MITM attacks on ntp - even on a per city or region basis to narrow down user sets. This is needed and for everyone, especially users who are not consistently online.
[b]Feature Request:[/b]A global adversary has all the time in the world to mount finely tuned MITM attacks on ntp - even on a per city or region basis to narrow down user sets. This is needed and for everyone, especially users who are not consistently online.
I suggest the inclusion of a script to automate the process of setting a random clock offset upon vm start-up. This will be included in the tar.gz file with the image and xml configuration files. A simple readme file with instruction (that I can write) on how to use this is important to guide users. Running scripts on startup can be accomplished through the GUI of most modern Desktop Environments and should not be an impediment to usability.
Yes.
[b]Feature Request:[/b]A global adversary has all the time in the world to mount finely tuned MITM attacks on ntp - even on a per city or region basis to narrow down user sets. This is needed and for everyone, especially users who are not consistently online.
I suggest the inclusion of a script to automate the process of setting a random clock offset upon vm start-up. This will be included in the tar.gz file with the image and xml configuration files. A simple readme file with instruction (that I can write) on how to use this is important to guide users. Running scripts on startup can be accomplished through the GUI of most modern Desktop Environments and should not be an impediment to usability.
Maybe I am not doing a good job explaining what I mean by offset.
When setting.
VBoxManage modifyvm "Whonix-Gateway" --biossystemtimeoffset +27931VM will be set 27931milliseconds in future, thus unlinking milliseconds from the host.
Our first step needs to be to find an equivalent of this command or setting for KVM. Have we already figured that out?
Next step would be having a script that automates this.
VBoxManage modifyvm "Whonix-Gateway" --biossystemtimeoffset +"$x"Where variable $x is a random integer between 500(?) and 99500.
Next step would be getting rid of the script by having this range a feature of the virtualizer.
A feature request for VirtualBox could be:
At the moment biossystemtimeoffset expects an integer in milliseconds.
It would be nice to have to support random ranges for biossystemtimeoffset, i.e. biossystemtimeoffsetmin -99500, biossystemtimeoffsetmax +99500. VirtualBox would then pick a random value between -99500 and +99500 and use that as biossystemtimeoffset.
This would help to defend against time based fingerprinting attacks.
Well, the feature request doesn’t sound so exciting. I doubt either VirtualBox or KVM developers will be excited about it. However, it is important to write https://www.whonix.org/wiki/Dev/TimeSync and the feature request as clear as possible, so as many people as possible understand it, so some day someone capable of C(++) can implement the feature for Whonix.
Exactly, this is much simpler and what I had in mind. It makes kvm Whonix uniform on all systems it runs on too. Its also the closest to an .ova drop-in replacement as possible. The images with the xml configuration that is imported with the exact optimal settings we decide on.[/quote]
Yes.
[quote] If so "start this extra script every here and now to randomize times" would make this more cumbersome.[/quote]On second thought, yes you are right about this making things needlessly complicated, but if its very important in situations where a hidden service is being sniffed out, then we should include a script for it with optional instructions in the wiki.
However I have an alternative last suggestion at making this setting applicable for everyone. How about adding to UTC some offset based on some country's timezone to solve this?Random time zones would only make hours relative, i.e. 02:53:45:35678 vs 05:53:45:35678 could still be linked.
This time random offset feature is about setting for example 02:53:45:35678 to 02:53:45:12563. After boot, bootclockrandomization kicks in and sets it +/- range between 5 and 180 seconds in future or past, for example setting 02:53:45:12563 to 02:53:23:12563. After Tor succeeded connecting, sdwdate kicks in and sets it to maybe 02:53:40:12563.
I decided to ask on #tor about the benefit of the random offset. Its clear that we have different views of the threat model, but I decided to post it anyway for reference.Well, I am not sure if this topic gets a little to complicated for irc support. They may not be aware of my arguments from https://www.whonix.org/wiki/Dev/TimeSync and the linked papers. Also I may not be doing a good job explaining this issue. Very few have raised criticism or questions about that page. Either - it is so perfect, that it can not be criticized. - it is so complex, too much text, that no one bothers to check - http://en.wikipedia.org/wiki/Parkinson%27s_law_of_triviality kicked in <--- timesync is like the atomic reactor, very few comment on these designs; whonix logo is the bikeshed, where many seem to know The Truth(tm)
[quote]Sounds like these filers are not supposed to be edited by hand? At least not while kvm is running? I guess they get reset by kvm. Your changes may persist when all kvm machines are shut down. Please try that.[/quote]ok I’ll check.
Edited to add:
Same thing happens with editing while vm shutdown, but the clocks are still separate.
It seems like editing xml files is not that simple. Needs two more commands. First dump the xml, then edit it, then re-import the xml. It is described here:
https://help.ubuntu.com/community/KVM/Managing#Editing_the_attributes_of_a_Virtual_Machine
Wrong recipient? I was thinking about a feature request against KVM, not Whonix. The KVM devs shouldn't add a script.Maybe I am not doing a good job explaining what I mean by offset.
No, you’ve explained it well and I understand it completely. The request I typed was just me being confused about who you meant. If they add this to their timer back-end then of course no script is needed. I will type the feature request here for proof-reading before I find and post it in the proper place. I don’t want to blow it and lose the interest of the few readers who could make this happen.
[b]Feature Request:[/b]Hello, this is a feature request, for adding the ability for the kvm timer back-end to spoof the initial virtual hardware clock offset by setting the clock X milliseconds, in the future or past, by picking a random value within a range of seconds chosen by the user. This is in contrast to what is only possible now, through only being allowed to pick a fixed and arbitrary timer offset.
VirtualBox has such a feature implemented by using this syntax:
VBoxManage modifyvm --biossystemtimeoffset -
VBoxManage modifyvm --biossystemtimeoffset +An important use case for this is the ability to defend against time fingerprinting attacks that could unmask anonymous users relying on Tor in their vms.
Thanks for your consideration.
Very few have raised criticism or questions about that page.Or maybe most people think its "paranoid" until it becomes common knowledge that this and more is being actively done. Same complacency before the Snowden era, but its up to us to take precautions against worst cases.
timesync is like the atomic reactor, very few comment on these designs; whonix logo is the bikeshed, where many seem to know The Truth(tm)Sad, but true. Though you've done your homework on this and it makes perfect sense to me.
Well, it seems like there is still a process running overwriting these files. I wouldn't know any other explanation why it keeps overwriting hand made settings. Or perhaps there is some kind of backup and integrity check, that restores the backup after hand made edits. How to hand edit xml files is a good question for search engines, irc, mailing listsI don't think that's whats happening because I've managed to add a line for kvmclock and edit it to not present, while the vm was running. Virtmanager always tells me that any edits I make will be applied on next vm startup too. I can look up the export/import/edit syntax for libvirt xml files if needed.
Well, the feature request doesn't sound so exciting. I doubt either VirtualBox or KVM developers will be excited about it. However, it is important to write https://www.whonix.org/wiki/Dev/TimeSync and the feature request as clear as possible, so as many people as possible understand it, so some day someone capable of C(++) can implement the feature for Whonix.
This. I am pessimistic about them listening to us and implementing what they could see as a ‘dsitro-specific’ feature. Upstream is very tough to communicate with and tend to ignore feature requests or questions that they see as dumb. What fallback advice or plan do we have if it turns out this won’t ever see the light of day?
Maybe its enough if users allow autosyncing with ntp once on the host and then manually alter it a little before turning this off on the host? Turning it off prevents active attacks in the future, and as long as the host clock is close to ntp time then I don’t think users will stand out.
This works out because, even if an adversary has already been doing global attacks during the event of a user’s first sync, they (the adversary) would have done so subtly and not changed the time so much as to not draw attention. Manually adjustment of a few seconds forwards or backwards is enough to muddy the waters. Not ideal but I believe it makes sense under this threat model. What do you think?
This explains why the setting i put keeps vanishing. I think its becuase of some wrong xml schema I’m using according to them. In this command they show, do I use the xml file name or the name of the vm to validate its input?
# virt-xml-validate libvirt.xml
[quote=“HulaHoop, post:53, topic:166”]libvirt: Common XML problems
This explains why the setting i put keeps vanishing. I think its becuase of some wrong xml schema I’m using according to them. In this command they show, do I use the xml file name or the name of the vm to validate its input?
Good finding. Worth to be added to Dev/KVM. I will be happy to add this command to the build process when using --kvm (or --qemu?) switch. Scripting this should be simple and the build process could fail closed (break) and early.
Added as non-blocker:
I am wondering how to best deploy this. I think we agree to deploy an xml file. Ideally, since xml files are difficult to create/edit by hand (that’s the reason, why I hate xml and prefer normal config files), it would be best if we provided the necessary commands to create such a file.
Once we have them, I am happy to write a script automating the process.
Added as non-blocker:
https://www.centos.org/docs/5/html/5.2/Virtualization/chap-Virtualization-Managing_guests_with_virsh.html
Creating a guest
Creating a virtual machine XML dump(configuration file)
In this link is info on dumping the xml from a vm too. But there is an important thing worth mentioning.
It turns out that dumping the xml for the virtual internal network is a separate affair. How to import it and use it, has many options too:
<< Managing your virtual network with the virsh command
Time offset
I am thinking about the time offset settings thing. When bootclockrandomization [which is now running before Tor and sdwdate] can be improved to also change milliseconds, then this feature can be omitted. I haven’t figured out yet how to change milliseconds using date, if this is even possible.
Scripting / xml
Ideally, we have a list of commands required to create the xml.
Looking like this.
virsh create Whonix-Gateway virsh setmem Whonix-Gateway kilobytes virsh attach-device Whonix-Gateway /path/to attach-interface Whonix-Gateway --mac mac ... virsh dump /path/to
You get the idea. This would be ideal to script (and easy to script) and perfectly auditable / extensible / clear.
I will see what I can find and keep you updated.
http://linux.die.net/man/1/date
The date can be set at the nanosecond level, with larger numbers being able to have an effect at the millisecond level.
Ideally, we have a list of commands required to create the xml.
Thats excellent.
Random time offset for nanoseconds has been moved forward.
Check out the updated bootclockrandomization script:
https://github.com/Whonix/Whonix/blob/master/whonix_shared/etc/init.d/bootclockrandomization
Copy to /etc/init.d/bootclockrandomization.
Test:
In one window:
tail -f /var/log/bootclockrandomization.logIn another window:
sudo service bootclockrandomization restartExample log.
- 142 422538623
Changed time from Sun Apr 6 00:23:55 UTC 2014 (1396743835.348288794)
to Sun Apr 6 00:21:33 UTC 2014 (1396743693.424668773).
- 23 718543726
Changed time from Sun Apr 6 00:21:34 UTC 2014 (1396743694.584517815)
to Sun Apr 6 00:21:11 UTC 2014 (1396743671.720666713).
+ 37 918148837
Changed time from Sun Apr 6 00:21:12 UTC 2014 (1396743672.198839644)
to Sun Apr 6 00:21:49 UTC 2014 (1396743709.920361623).Please review!
root@host:/home/user# tail -f /var/log/bootclockrandomization.log to Sat Apr 5 00:52:34 UTC 2014. + 165 Changed time from Sat Apr 5 12:56:45 UTC 2014 to Sat Apr 5 12:59:30 UTC 2014. - 51 Changed time from Sun Apr 6 02:33:34 UTC 2014 to Sun Apr 6 02:32:43 UTC 2014. + 111 029733597 Changed time from Sun Apr 6 02:59:25 UTC 2014 (1396753165.481980210) to Sun Apr 6 03:01:16 UTC 2014 (1396753276.033997830).
Looking good 
What is your opinion about this suggestion used in combination with the updated script? If useful, we could add it as a readme in the tar.gz. If not needed, then nevermind.
Maybe its enough if users allow autosyncing with ntp once on the host and then manually alter it a little before turning this off on the host? Turning it off prevents active attacks in the future, and as long as the host clock is close to ntp time then I don't think users will stand out. This works out because, even if an adversary has already been doing global attacks during the event of a user's first sync, they (the adversary) would have done so subtly and not changed the time so much as to not draw attention. Manually adjustment of a few seconds forwards or backwards is enough to muddy the waters