qvm-create-windows-qube icon indicating copy to clipboard operation
qvm-create-windows-qube copied to clipboard

Clock in VMs do not maintain sync

Open ew0k opened this issue 2 years ago • 5 comments

This problem is such a headache. I have tested and experienced it on Win10 enterprise, ltse and pro. The VMs simply refuse to maintain sync. The enterprise and LTSE VMs refuse to sync to any of the time servers. You can manually set the clock but after a reboot the clock loses sync it can be up to a few hours to a day. The PRO vm i just setup now will sync with timeserver and get the correct time and instantly reboot it and the clock is out of sync a few hours.

Desperately looking for some help diagnosing this issue.

Thanks

ew0k avatar Oct 30 '21 20:10 ew0k

Running Qubes 4.0.4 btw

ew0k avatar Oct 30 '21 20:10 ew0k

Unless anything has changed since this 2015 mailing list message (and through my research I don't believe much has), clock synchronization in Qubes works in a very primitive fashion by simply calling qvm-sync-clock every six minutes.

Linux client-side code: https://github.com/QubesOS/qubes-core-admin/blob/master/qvm-tools/qvm-sync-clock Windows client-side code: https://github.com/QubesOS/qubes-core-agent-windows/blob/master/src/qrexec-services/set-time.ps1

I'm aware that clocks reset every time the VM reboots, it's something I had to take take into when I was making the Windows-Whonix-Workstation skew clock feature: https://github.com/elliotkillick/qvm-create-windows-qube/blob/4e07e4b5c76f7b558b569360e2cb52b4542c8431/post/whonix.bat#L22-L24

This is something that all Qubes VMs do and is not unique to Windows.

However, the clocks losing sync to that severe degree is something I haven't experienced.

Can you please verify the following:

1. Go to /etc/qubes-rpc/policy/qubes.GetDate in Dom0 and make sure it has has these lines (at least this is what its contents are on my R4.0 system):

$tag:anon-vm	$anyvm	deny
$anyvm	$anyvm	allow,target=dom0

Note that if Windows does not have access to the aforementioned Qubes RPC service it will default to UTC as is configured here for all answer files:

https://github.com/elliotkillick/qvm-create-windows-qube/blob/4e07e4b5c76f7b558b569360e2cb52b4542c8431/windows-media/answer-files/win10x64-pro.xml#L57

This is desirable for Whonix mode and until QWT is installed for privacy purposes (but not pass that).

2. Your BIOS/UEFI time is set correctly

  • This is where the default Xen clocksource gets its time so it being correct is important. Without the Qubes RPC time service, Windows will fallback to this (unless Internet time synchronization is enabled in which case Windows will prefer that once it's fetched).

3. Your Windows machine is on the correct timezone

  • Run this in CMD: tztuil /g

4. The time and timezone is correct on your other Linux AppVMs:

  • Run this in a terminal: timedatectl

Also, try running this in CMD: tzsync

ElliotKillick avatar Nov 01 '21 05:11 ElliotKillick

Thank you so much for taking the time to respond. I have followed all these steps and here are my results:

  1. My Dom0 is exactly the same.
  2. I have confirmed the time displayed in the BIOS for the PC is correct
  3. My VMs will have a different time zone. For whatever time zone I have set it to the clock is constantly out of sync.
  4. The time zone on all my other VMs (debian, fedora, whonix) are all correct and in sync.

Just to recap: I have setup 2 windows VMs via whonix (ltse, enterprise) - the sync does not work on these VMs full stop. You always have to set the time manually after each reboot. The clock on these VMs its just chaos each time. I think they are even losing sync during a session but I have not confirmed. The last successful sync time with timeservers shows as 2015. It refuses to sync with any remote timeservers when pressing the 'sync now' button - it will just timeout.

I have setup 1 win10 pro VM without whonix config during setup just using sys-firewall - pressing the sync button (toolbar-->clock-->adjust time and date) the vm will connect to Microsoft servers and sync successfully. After reboot, even if right away, the clock will go back out of sync 1h or 2h. Usually its exactly 1h or exactly 2h unlike the VMs above which can be off by totally random amounts.

What do you suggest I do?

ew0k avatar Nov 07 '21 06:11 ew0k

I have setup 2 windows VMs via whonix (ltse, enterprise) - the sync does not work on these VMs full stop

This is to be expected, as was advised in the official Whonix-Windows-Workstation documentation, I disabled Internet Time Syncing:

https://github.com/elliotkillick/qvm-create-windows-qube/blob/4e07e4b5c76f7b558b569360e2cb52b4542c8431/post/whonix.bat#L14-L15

Additionally, I add the anon-vm tag to Whonix-Windows-Workstations thus denying them access to the qubes.GetDate service:

https://github.com/elliotkillick/qvm-create-windows-qube/blob/deb3a1fb174438576d21063a8b8d472181197476/qvm-create-windows-qube#L396-L400

At the time I implemented this, I wasn't quite sure the effect this would have (just following Whonix docs, copying what was done for Whonix-Workstation VMs), however, maybe it wasn't the wisest idea because while Whonix-Workstations have swdate for accurately setting the time while skewing it just a little for privacy purposes, Windows-Whonix-Workstation has no such feature. Although, I figured the Whonix-Windows-Workstations could probably still get the BIOS time (Xen clocksource) to sync or something.

I may have to stop adding that anon-vm tag (at a slight cost to privacy in the case of VM compromise) if this is the effect it will have.

However, even still the clock of all of your non-Whonix Windows VM should be synced up by the qubes.GetDate service.

For your non-Whonix Windows 10 Pro VM:

If it's always a few hours out of sync then that sounds like a time zone issue. Is it possible that your BIOS clock is synced to your local time when it should really be UTC (or vice versa)? Try taking your correct local time and converting that to UTC. Is it the same as what your Windows VM is saying the time is?

You could also probably fix this issue by enabling the Windows Time service to start at boot (and rebooting): sc config W32Time start= auto

However, that's really just a workaround because the qube.GetDate service should be able to do it once QWT is installed.

Also, make sure to give timedatectl a run in Dom0, your XFCE clock doesn't necessarily display the same time/timezone.

At this point, I'm just throwing out ideas but also try running sudo qvm-sync-clock in sys-net (the default ClockVM), then timedatectl and restarting Windows.

Lastly, I thought you also may be interested in the following upcoming change to time syncing in Qubes: https://github.com/QubesOS/qubes-issues/issues/7081

ElliotKillick avatar Nov 25 '21 07:11 ElliotKillick

Windows services are often up and running before the network, especially the IPv4 layer. Try setting a static ip address, not just a static lease. Unlike Linux, many services do not recover well if the service was started before IPv4 connectivity was up. For network related services, goto the "Recovery" tab to set "Restart the Service" on at least First and Second Failure if not all subsequent failures. Need a way to get and set these service failure actions from PS, but have not found a solution.

"nsi","w32time","DHCP","dnscache" | get-service | fl

rjt avatar Feb 02 '22 03:02 rjt