ID: 431PHID: PHID-TASK-c4ijkloku4sduej5ngb4Author: PatrickStatus at Migration Time: openPriority at Migration Time: Normal
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
Quote Xen project Mailing List
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 had|has /proc/sys/xen/independent_wallclock
if applicable, explain upstream and write feature requests
2015-11-21 00:52:03 UTC
The Clock Mini-HOWTO: How Linux Keeps Track of Time
" 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. "
[Qemu-devel] Question on kvm_clock working ...
" 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.
2015-11-21 01:29:41 UTC
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)?
Phrased differently…
e) From which source does the kernel initially obtain the time to set the kernel clock?
2015-11-24 22:10:33 UTC
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:
http://lxr.free-electrons.com/source/Documentation/virtual/kvm/timekeeping.txt
2015-11-24 23:04:49 UTC
2015-11-25 03:18:10 UTC
2015-11-25 13:22:26 UTC
! In T431#7301, @HulaHoop wrote:
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-additions for KVM, this task cannot be automated. Unfortunately there is no randomization feature. It would be worthwhile requesting one upstream. (Created T439 for it.)
2016-09-05 14:10:37 UTC