ID: 385PHID: PHID-TASK-dpy2ikajfp3lmslgvrlyAuthor: HulaHoopStatus at Migration Time: openPriority at Migration Time: Normal
More testing was done, inspired by the information here: virtualization - How to keep time on resumed KVM guest with libvirt? - Server Fault
If date command sets system time during a session it will be honored even after a system-resume meaning sdwdate’s time will stay the same even after resume with kvmclock available. If date command is never run during a session, the kvm-clock hwclock automatically adjusts system time after resume. kvm-clock always keeps up with host time. Running “sudo hwclock” confirms this.
Given this information, to make sdwdate work with hwclock (kvm-clock) it must monitor the difference between date command output and hwclock. Just like the loop check mechanism in the other ticket. If it exceeds certain delta time it would synchronize the system time to match that of hwclock with command:
sudo hwclock --hctosys
The running of timesync on WS would be slightly delayed (for 30s) to give time for sdwdate GW to set a baseline time from hwclock to allow Tor to connect.
Advantages of this ticket:
No extra packages needed
No security tradeoffs cased by guest-agents
No intervm signalling needed
Works in both GW and WS
It is safe to enable kvmclock because it doesn’t interfere with the time set by sdwdate. We already decided in the threat model discussed in: Time Attacks - Whonix that even without giving access to kvmclock timesync cannot protect against active attacks by an adversary inside the WS.
To enable kvmclock the settings need to be reverted to:
and whonixcheck should disable its kvm-clock warning.
2015-07-29 19:17:06 UTC
2015-07-29 19:20:45 UTC
2015-07-29 19:35:03 UTC
2015-07-29 19:41:20 UTC
I’m confused is biossystemtimeoffset a whonix-host package?
The threat model considers active skew attacks against hosts running NTP too. A small offset against a skew of say 5 or 10 minutes will not help.
Either way the package won’t hurt.
2015-07-29 21:53:54 UTC
I’m confused is biossystemtimeoffset a whonix-host package?
biossystemtimeoffset isn’t a package. It’s a VirtualBox setting. One that was previously recommended to users to manually set. Other virtualizers might have similar settings. We’ve discussed this at the early stages of KVM port. Not sure if KVM had it. We deprecated it because of the introduction of bootclockrandomization. Here is the deprecated documentation:Outdated, Deprecated, Archived Whonix Documentation.
I keep writing ‘biossystemtimeoffset alike’, because I haven’t found a good virtualizer agnostic term yet.
The threat model considers active skew attacks against hosts running NTP too. A small offset against a skew of say 5 or 10 minutes will not help.
Depends. There are threat models in which the adversary doesn’t know who’s NTP clock to skew. Also not all adversaries are capable of it. On the other hand, controlling a few web servers that are receiving local clock leaks (ex: javascript) by many users and at the same time having compromised a Whonix-Workstation might not be a that unlikely threat model. In that cases, biossystemtimeoffset alike approaches are still very much worth it.
2015-08-04 15:52:23 UTC
2015-08-04 21:14:05 UTC
2015-08-04 21:15:18 UTC
2015-12-16 21:40:37 UTC
latest results:
switched off bootclockrandomization + swdate servcies
Upon resume guest softclock is perfectly in sync with system. hwclock is not.
Wihout kvmclock both the softclock and hwclock are not synced.
Exact same results with swdate and bootclockrandomization left on. The time set by sdwdate is honored until a host standby/resume event which causes th softclock in the vm to sync.
The only time the clock does not sync to the host’s is when the guest is delayed by saving or pausing but that has nothing to do with normal opeation.
I think its best that the kvmclock warning is disabled on gw so it can be left to use kvmclock normally. There is nothing unsafe about it. It would have been the exact same effect with the qemu guest-agent solution except the latter is not ready and would have required extra packages and settings to configure.
2015-12-17 20:01:49 UTC
Given that setup… If you freeze the gateway for more than let’s say 3 hours, is Tor actually able to recover from this - from Tor’s perspective - time warp?
issues with that proposal:
gw solution only, ws would still continue to use the slow clock
assuming a compromised gateway, would still violate the goal to have a fully independent VM clock [to protect the host and other VMs; to a lesser importance, also to protect time attacks when using additional (VPN or w/e) gateways in front that the compromised Whonix-Gateway)
using just kvmclock after suspend contradits the reason for running sdwdate on the gateway in the first place
2015-12-18 17:02:31 UTC
! In T385#7669, @Patrick wrote:
Yes
issues with that proposal:
gw solution only, ws would still continue to use the slow clock
Not different from whats happening now, but thats what sdwdate is for. At least it will work now that the gw is still connected to Tor.
assuming a compromised gateway, would still violate the goal to have a fully independent VM clock [to protect the host and other VMs; to a lesser importance, also to protect time attacks when using additional (VPN or w/e) gateways in front that the compromised Whonix-Gateway)
IMO a compromised gw means game over and the clock reading is the least thing a user should worry about at this point. We can also agree that running Tor thru a VPN isn’t much help if the Tor/gw anonymity is broken.
using just kvmclock after suspend contradits the reason for running sdwdate on the gateway in the first place
Not necessarily because the gw clock will honor the time set by sdwdate. The current time supplied by kvmclock is also no different than what would happen when I restart the gateway now so it updates its clock for Tor to work.
A bonus usability feature is to have some script in the gateway running in a loop and detect softclock jumps and trigger a sdwdate run for both gw and ws somehow but its probably difficult. Even without this, usability improves than what it is now and manual running of sdwdate after resume is seamless in the ws across suspend/resume sessions.
2015-12-19 20:03:01 UTC
HulaHoop (HulaHoop):
assuming a compromised gateway, would still violate the goal to
IMO a compromised gw means game over and the clock reading is the
In the use case of using Tor for non-anonymous use, location privacy,
using just kvmclock after suspend contradicts the reason for
Not necessarily because the gw clock will honor the time set by
Then you would at least have bootclockrandomization before Tor connects.
From the Dev/TimeSync Page:
Using Boot Clock Randomization, i.e. after boot, the clock is set
You could say, no longer required, because there are no more local clock
2015-12-20 18:33:32 UTC
If Tor is broken then everyone’s protection is gone just as if they are using the clearnet. Everyone no matter the threat model would be completely hosed. VPNs won’t save them because plain SSL as a protocol and VPN design as single point of failure is why they cannot anonymize traffic. At that point the attacker will know a lot more valuable information than the local time about everyone.
Then you would at least have bootclockrandomization before Tor connects.
OK Good. Please adjust the pv_clock function to check on ws only because I want to enable kvmclock on the gw.
You could say, no longer required, because there are no more local clock leaks.
Thats right and I would be willing to revisit this should evidence otherwise arise but thats unlikey because all the papers covering this point to things that have been handled already for the protocols in question on the gw.
2015-12-21 11:46:55 UTC
HulaHoop:
If Tor is broken then everyone’s protection is gone just as if they are using the clearnet. Everyone no matter the threat model would be completely hosed.
Define completely hosed. Your threat model seems to be, ‘once
Let’s say there is a scale of 0 to 10 of priority where 10 is the
prevent compromise of location privacy [Whonix-Gateway]
prevent compromise of bank VM
prevent compromise of vault VM
prevent compromise of host / hardware
prevent compromise of air gapped system
Now, by making it easier to to break priorities 7 to 10, in case
Granted, there are certainly people who assign highest priority ‘10)
The ability to have Whonix-Gateway running after prolonged suspend is a
The conflicting priorities here are, out of the box usability vs
Then you would at least have bootclockrandomization before Tor connects.
OK Good. Please adjust the pv_clock function to check on ws only because I want to enable kvmclock on the gw.
What I wrote was not good, unfortunately.
Patrick:
using just kvmclock after suspend contradicts the reason for running
HulaHoop:
Not necessarily because the gw clock will honor the time set by
Patrick:
Then you would at least have bootclockrandomization before Tor connects.
To specify what I meant…
When gateway boots → bootclockrandomization → Tor connects with time
On resume → kvmclock sets time to host time → Tor connects with same
That’s what I meant by “Then you would at least have
You could say, no longer required, because there are no more local clock leaks.
Thats right and I would be willing to revisit this should evidence otherwise arise but thats unlikey because all the papers covering this point to things that have been handled already for the protocols in question on the gw.
Created T458 for it.
2015-12-21 21:50:46 UTC
Define completely hosed.
If they are sitting on the gw they can see a lot more than the time shown by the vm clock, which does not leak to the network otherwise.***** At that point, knowing what the host time is is no longer important when they can see everything.
I am not speaking about consequences that will happen to different people depending on what they do.
I feel this topic has become a bikeshed argument detracting attention from more important things. I understand your intentions are good but blocking a simple change that will improve usability a lot is not something I agree with especially when you don’t use this particular port yourself everyday.
*****I would like to test the apt traffic with tshark to assure you.
2015-12-21 22:00:20 UTC
What are the other things they can see? Especially which ones aid to
I admit there is a lot love put in the details here. I just don’t want
The final decision in this case is up to you.
I’ll make the changes in whonixcheck.
2015-12-21 22:06:14 UTC
2015-12-22 01:31:48 UTC
2016-04-27 20:48:52 UTC
2016-08-23 19:53:20 UTC