http://www.tldp.org/HOWTO/Clock-2.html

" 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. "

http://lists.gnu.org/archive/html/qemu-devel/2011-09/msg01249.html

" 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:

http://lxr.free-electrons.com/source/Documentation/virtual/kvm/timekeeping.txt

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.