Page MenuHomePhorge

Whonix running as Qubes DispVM uses saved clock
Closed, WontfixPublic



When running as Qubes DispVM, whonix-ws sometimes (often) does not set the clock correctly, but instead seems to restore the date/time from when the DispVM savefile was created.

I have seen this often, over a very long period, but always assumed it had to do with my DispVM customisation. This time, I set up a clean Qubes R3.2, updated whonix-gw template and created a DispVM without customisation. The problem still occurs.

I usually don't find out until I start getting OCSP errors due signatures being in the future. But this means that most likely a lot of earlier browsing has been correlateable since it all had the same wrong clock, therefore I set the priority of this ticket to high since it is a possible anonymity leak.

Recreating the DispVM savefile gets a more up-to-date clock in DispVMs launched afterwards.

Steps to reproduce:

  • Install Whonix templateVM on Qubes
  • Update the template (through qubes manager GUI action) and shut it down
  • qvm-create-default-dvm whonix-ws
  • Wait a couple of days
  • Launch DispVM, start getting OCSP time errors on browsing. Note that system time is wrong.



Event Timeline

@marmarek this is probably due to Qubes current DispVM savefile implementation? It should fix itself in Qubes R4.0 since DispVM implementation changed there?

This does not seem to happen every time, strangely enough. It seems sdwdate should call qubes.GetRandomizedTime as a post-suspend action if I read this correctly. So I guess under some circumstances that step does not run.

I am currently investigating this issue further, running a loop on dom0 that creates DVMs, checks time and leaves it running if the time is outside acceptable range.

I'll comment here if something comes of it.

Yes to both of you:

  • should just work on Qubes 4.0 (savefiles are not used there anymore)
  • calling qubes.GetRandomizedTime as post-suspend action would fix that too
Patrick claimed this task.

Unless someone else will be taking this one...

Time wise only possible solution currently: wait for Qubes 4.0.

I didn't notice this bug earlier but caught a reference in one of the Qubes mailing list discussions. For what it's worth, I got this to function under Qubes 3.2 by deleting the sdwdate systemd unit files. It has been a while but I think I did that in the whonix-ws template. The dispvm appears to call bootclockrandomization on every start so time correlation is avoided and I no longer encounter times off by 2+ weeks.

Would it be helpful if I started from a fresh whonix-ws template and documented the exact steps I followed for 3.2? It's possible there's some attack I haven't thought of.

Qubes-Whonix DispVMs won't get any more development attention in Qubes
R3.2 because so much has changed. Please look into Qubes R4.