KVM does not have a way to introduce a random offset to a VM's clock. The offset is arbitrary and static so I don't think it will be useful.

Doesn't need to be random. Why isn't a static one useful? Just needs to be a custom number. Only known to the host. Not known to public and/or the guest VM. It wouldn't be useful to deploy this by default, because then the offset would be known. This is something in context for advanced security guide. Every advanced user is expected to make up their own numbers and adding this to the VM setting by themselves. That's why this ticket's project is user documentation and not whonix-libvirt.

Against an active attacker, static offsets and (random too to an extent) are not that effective. They can actively manipulate host NTP and figure out that the Whonix guest sits on a host machine of a certain target set. Say the real time is 1:30 they skew it to 1:15 for a certain target country - probably much less in real life to avoid being noticed but even a few seconds is enough then upon reboot the in the rooted VM they see its 1:15 + 5 seconds or even some random offset between 30seconds to a minute, this still won't be enough to disguise the fact that the host falls within a targeted set.

This attack seems hard but remember large network adversaries have all the time in the world (no pun intended) and can skew it subtly for as many people/areas as they can.

The only way to protect against this is to not leak host time at all so there is nothing to compare VM time to.

Did you notice how this raised the bar? From just...

a) passive ISP level adversary + Whonix-Workstation exploit -> correlate time attack succeeds

to

b) host time offset + active ISP level adversary to manipulate NTP against many users [which risks getting this detected] + Whonix-Workstation exploit -> correlate time attack success

So that alone would make it worth to apply this setting.

It happens in context of advanced security guide. So there is no NTP on the host. Nothing to skew in the first place. Static offsets therefore should work.

Its trivial to document, that's not the problem, but I'm trying to see if it makes sense.

It happens in context of advanced security guide. So there is no NTP on the host. Nothing to skew in the first place. Static offsets therefore should work.

Right, in the context of someone following the advanced security guide, this won't gain them any more protection than what they already have because I assume they will not be running anything in the clear on the host either.

For hose not following any of the advice they will be safe as things are but only against a passive adversary.

This is a defense in depth. It's hard to be 100% sure, local clock has never leaked, no? Even if they avoid clearnet traffic while browsing anonymous, how realistic is it to ask to never use clearnet ever again? If the clock leaked before they had applied all these settings, then they're better off spoofing the time offset.

Change:

<clock offset='utc'>

to

<clock offset='variable' adjustment='123456' basis='utc'>

adjustment takes any arbitrary value of seconds. Pick a random number of seconds only known to you.

That's it basically. Can you add this to the wiki please? And expand it a bit? (See the VirtualBox example. There is somewhat a suggested limit for the range. But the best range can be audited and revised if applicable.) Then this ticket can be considered resolved.

Where on the wiki should I post this?

OK I see

Thanks for your edit.

https://www.whonix.org/wiki/Advanced_Security_Guide#KVM does this work? Did you test it with a big enough noticeable amount?

I tried it with 123456 seconds and it pushed time in the vm the expected 34 hours in the future.