without giving access to kvmclock timesync cannot protect against active attacks by an adversary inside the WS

Why not? With a biossystemtimeoffset alike feature it could.

If we presuppose an active attacker sitting inside WS they could easily disable biossystemtimeoffset, no?

No. Because that's a virtualizer specific setting applied on the host. Not inside the guest.

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.

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:
https://www.whonix.org/wiki/Deprecated#VirtualBox_spoof_the_initial_virtual_hardware_clock_offset
If you search the wiki for 'biossystemtimeoffset', you'll find some more. However, for better comfort and adaptation, this would suit perhaps into the context of a whonix-host package.

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.

I tried running these settings again today but I couldn't reproduce them at all even after a clean boot. This ticket is dead reopening 381.

document Spoof the Initial Virtual Hardware Clock Offset for KVM:
T388

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

In T385#7669, @Patrick wrote:

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?

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.

HulaHoop (HulaHoop):

• 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.

In the use case of using Tor for non-anonymous use, location privacy,
other VMs or the host should not be more vulnerable than necessary. The
location privacy use case is for example what Appelbaum uses Tor for.
Also the other the "I have nothing to hide but my privacy" crowd should
care. "least thing a user should worry about at this point" only applies
to some part of users. We appreciate the "I have nothing to hide but my
privacy" crowd so those who really need anonymity have the required
company to hide.

• using just kvmclock after suspend contradicts 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.

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

randomly between 5 and 180 seconds into the past or future. This is
useful to enforce the design goal, that the host clock and
Whonix-Workstation clock should always slightly differ. It's also useful
to obfuscate the clock when sdwdate itself is running, because naturally
at this time, sdwdate hasn't finished.

You could say, no longer required, because there are no more local clock
leaks. But I am not so sure really all local clock leaks have been even
found. This is because I was involved in reporting some of these local
clock leaks. They were only fixed, because by chance I happened to read
historic Tor trac development discussions, and then using logic to draw
the right conclusions, then reported bugs. I didn't read the related
source codes nor checked with a traffic analyzer that there are no other
local clock leaks. And I find it very likely, that no one else ever did
that either, because these issues remained unnoticed for years.

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.

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
deanonymized = literally imprisoned or dead'. That may be true for some
people, but certainly not the majority or all.

Let's say there is a scale of 0 to 10 of priority where 10 is the
highest priority. And where you cannot have the same priority for
everything for practical reasons. For example, personal preferences
could be something like this:

6. prevent compromise of location privacy [Whonix-Gateway]
7. prevent compromise of bank VM
8. prevent compromise of vault VM
9. prevent compromise of host / hardware
10. prevent compromise of air gapped system

Now, by making it easier to to break priorities 7 to 10, in case
priority 6 was compromised, seems like a sellout to me.

Granted, there are certainly people who assign highest priority '10)
loss of anonymity'.

The ability to have Whonix-Gateway running after prolonged suspend is a
usability feature that also needs its priority assigned.

The conflicting priorities here are, out of the box usability vs
disaster containment.

> 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

sdwdate on the gateway in the first place

HulaHoop:

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.

Patrick:

Then you would at least have bootclockrandomization before Tor connects.

To specify what I meant...

When gateway boots -> bootclockrandomization -> Tor connects with time
different from the host

On resume -> kvmclock sets time to host time -> Tor connects with same
time as the host

That's what I meant by "Then you would at least have
bootclockrandomization before Tor connects.". I.e. "after boot, you
would at least have bootclockrandomization before Tor connects. This was
to illustrate that this would not be the case on resume -> kvmclock.
Then Tor would connect with plain host time. (And a compromised gateway
would have always access to the exact host time.)

> 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.

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.

What are the other things they can see? Especially which ones aid to
break out to the host? I guess we need a list on that also.

I admit there is a lot love put in the details here. I just don't want
any details be lost. Certainly something worth pointing out in advanced
security.

The final decision in this case is up to you.

I'll make the changes in whonixcheck.

https://github.com/Whonix/whonixcheck/commit/88ce7981e57b564aef421aebdbd3e7174c7517c8

(Untested. But likely working. To test this, emulate these changes or install latest whonixcheck from git master. [all git commits are signed])

https://github.com/Whonix/whonix-libvirt/pull/24

This also needs to be mentioned in the Whonix 13 releases notes so users can update their existing libvirt xml files.

Related:
Seamless Time-sync after Suspend-Resume has been implemented for Qubes-Whonix 13.
https://github.com/QubesOS/qubes-issues/issues/1764

What is the status of this? @HulaHoop