Running two sdwdate daemons all the time sounds awful. Thinking of a simpler solution.

Could we add a --oneshot feature to sdwdate that would only output a unixtime string? I.e. instead of setting the time, just writing it to stdout and exit?

(And somehow not mess up sdwdate daemon's logs. Perhaps we'd also need switches to configure log location.)

I can imagine a much simpler implementation to make Qubes-Whonix-Gateway work as ClockVM. Similar to dom0 qubes.GetRandomizedTime.

sys-whonix could re-use the very same script as qubes.SyncNtpClock.

Looks simple enough. Could do this even for Whonix 13. I haven't fully thought it through yet. The obvious disadvantage would be the the dom0 clock not being as accurate. Whatever consequences that may have. So we would have to regard this feature as experimental.

Interesting idea, but probably something better is needed. If this would
be used directly, every qubes.SyncNtpClock would return time with
different offset. Which means frequent clock jumps in dom0 (and VMs),
both forward and backward.
Maybe a simple improvement would be enough: choose an offset at
Qubes-Whonix-Gateway startup time and use that value until its shutdown?

There is also an interesting interaction to be thought through. sys-whonix -> gets suspended -> gets resumed -> calls dom0 qubes.GetRandomizedTime -> gets time from dom0 -> restarts sdwdate. At a close time, dom0 might call sys-whonix qubes.SyncNtpClock. So we would have a circle.

After sys-whonix was resumed, perhaps sys-whonix qubes.SyncNtpClock should either
a) block until sdwdate succeeded
b) exit non-zero
?

marmarek (Marek Marczykowski-Górecki):

Maybe a simple improvement would be enough: choose an offset at
Qubes-Whonix-Gateway startup time and use that value until its shutdown?

Sounds good!

After sys-whonix was resumed, perhaps sys-whonix qubes.SyncNtpClock should either
a) block until sdwdate succeeded
b) exit non-zero
?

Better exit non-zero. Then other VMs will have time synced with
dom0 clock. Blocking will delay other VMs clock sync (those VMs will
have time from before suspend). And it may be a long time, because user
may be in totally different location, without network access, so sdwdate
will not succeeded.

I was wondering, how big should be the offset? +/- x seconds?

• Let's assume Qubes-Whonix-Gateway sdwdate got a real good time fix, very similar to NTP accuracy. Then the offset would mess up that accuracy a lot and thereby lower anonymity.
• Let's assume Qubes-Whonix-Gateway sdwdate got a real bad time fix (for example + 220 seconds drift), then any offset would miss the design goal (as per the first bullet point in this ticket description).

All of that speaks for independent sdwdate daemons.

On the other hand I really like the offset approach and wish to find a sane implementation path. This is because implementing Qubes friendly sdwdate-gui (T534) would be really hard. Therefore I was wondering if the offset approach could not be made the default mode of operating. I mean, Whonix-Gateway could run a sdwdate-master and all Whonix-Workstations and other systems (dom0, other VMs) could periodically use a sdwdate-slave and request its time from Whonix-Gateway.

Would require somehow multiple numbers of offsets. I.e. X offsets, since the gateway cannot know how many workstations will be started. Or X sdwdate daemons.

Or somehow the sdwdate --oneshot approach and blocking, but then we'd have the issues resulting from blocking that you described.

Somehow need to find a way so T534 would not have to be implemented, so seeing sdwdate status of Whonix-Gateway only would suffice.