Page MenuHomePhabricator

wall clock likely readable by VMs allowing Clock Correlation Attacks
Open, NormalPublic


Upon start of a VM, it gets its initial time from the host.* Therefore we can conclude by logic, that the virtualizer must somehow provide access of the information (the host time) to the VM.

There are two different mechanisms not to be confused

  • kvmclock - which Whonix KVM libvirt xml files are explicitly not using because of this
  • wall clock


there is also a pv wallclock (i.e. date and time) interface, but I don't think that's what Linux's clocksource is about

An adversary with the capability to compromise a Whonix-Workstation VM + observer local clock leaks can run a clock correlation attack. Described in more detail here:

*Unless advanced users reading advanced security guide apply Spoof the Initial Virtual Hardware Clock Offset instructions. (Probably very few are doing this.)

TODO research:

  • gather more information on the wall clock interface
  • find out if the wall clock information is only provided to the VM upon start of the VM or if the wall clock is continuously updated
  • figure out what can be done about this
  • perhaps enable some "only update wallclock at VM start time" feature if available
  • see if KVM has something similar to what Xen [had|has](?) /proc/sys/xen/independent_wallclock
  • if applicable, explain upstream and write feature requests



Event Timeline

Patrick created this task.Nov 16 2015, 3:53 AM
Patrick updated the task description. (Show Details)
Patrick raised the priority of this task from to Normal.
Patrick added projects: KVM, security, bug, research.
Patrick set Impact to High.
Patrick added subscribers: Patrick, HulaHoop.
HulaHoop added a comment.EditedNov 21 2015, 1:50 AM

" A Linux system actually has two clocks: One is the battery powered "Real Time Clock" (also known as the "RTC", "CMOS clock", or "Hardware clock") which keeps track of time when the system is turned off but is not used when the system is running. The other is the "system clock" (sometimes called the "kernel clock" or "software clock") which is a software counter based on the timer interrupt. It does not exist when the system is not running, so it has to be initialized from the RTC (or some other time source) at boot time. "

" By default the RTC is driven by the host system time. This allows to use the RTC as accurate reference clock inside the guest, specifically if the host time is smoothly following an accurate external reference clock, e.g. via NTP. If you want to isolate the guest time from the host, even prevent it from progressing during suspension, you can set clock to "vm" instead. "

Yes the wall clock and kvmclock are not mutually exclusive. Both are taken care of by the current configuration because kvm-clock is disabled and the rtc timer is set to track the guest clock instead of the host.

Hardware clock is yet another thing. What is the output of sudo hwclock? I suppose, probably it's not accessible, right?

I don' think we sufficiently understand the wall clock mechanism. Even if the rtc timer is set to track the guest clock...

Upon start of the VM, the VM must somehow figure out the time. Is it,

  • a) Sat Nov 21 01:16:31 UTC 2000
  • b) Sat Nov 21 01:16:31 UTC 2015
  • c) Sat Nov 21 01:16:31 UTC 2030
  • d) etc.?

Likely the virtualizer has written this information into a memory page. Questions:

a) Can we access this information (date / time)?
b) How to access this information (date / time)?
c) Is this information (date / time) set to a fixed value (time of start of the VM) or sometimes updated (always same like host)?
d) Does this information (date / time) get deleted after using it for setting the kernel clock?

Phrased differently...

e) From which source does the kernel initially obtain the time to set the kernel clock?

I'll look into hwclock later. True, any guest on any virtualizer bootstraps its time initially from the host because it has to get it from *somewhere*. There is no way around that besides configuring an offset but then the attacker can just shave off the offset if they detect they're in a VM. I thought we agreed that the only effective solution for this was to stop time leaks from the host which is possible.

Linux documentation for timekeeping virtual and physical:

How can an attacker shave off the offset? [assumption: contained inside VM / no VM break out]

It will be known from the configuration files we distribute. Then all they have to do is deduct that number from whatever time they see inside the workstation to estimate the host time.

In T431#7301, @HulaHoop wrote:

It will be known from the configuration files we distribute. Then all they have to do is deduct that number from whatever time they see inside the workstation to estimate the host time.

Ah. Yes. That's why we don't distribute configuration files with time offset to a public known fixed value. And currently only have this advice in advanced security guide Spoof the Initial Virtual Hardware Clock Offset. Without Whonix-Host for KVM, this task cannot be automated. Unfortunately there is no randomization feature. It would be worthwhile requesting one upstream. (Created T439 for it.)

Same as T439 no wall-clock guest or otherwise provided any longer.