More testing was done, inspired by the information here: https://serverfault.com/a/694543
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 dwdate GW to set a baseline time from hw clock 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: https://whonix.org/wiki/Time_Attacks 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:
<timer name='rtc' tickpolicy='catchup'/>
<timer name='pit' tickpolicy='delay'/>
<timer name='hpet' present='no'/>
and whonixcheck should disable its kvm-clock warning.