Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign up'timekeeping watchdog: Marking clocksource 'tsc' as unstable, because the skew is too large' - may lead to connection and privacy issues #2044
Comments
adrelanos
referenced this issue
Jun 3, 2016
Closed
VMs with Whonix-Tor networking timeout and do not recover #1779
andrewdavidwong
added
bug
C: templates
P: major
privacy
labels
Jun 3, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Jun 4, 2016
Member
Does it happen after system suspend? That may cause Marking clocksource 'tsc' as unstable message.
As for the clock skew, clock synchronization mechanism in Qubes is quite inaccurate. First of all, it has 1 second precision. But then it is performed by:
- Call
date -u -Isecondsin dom0. - Pass the output to
qubes.SetDateTimeRPC service.
There may be arbitrary large time between those two, depending mostly on system load. In most cases it should be in order of milliseconds. Shouldn't be a problem for any connectivity.
But how that would lead to privacy problems? AFAIR you've told that slightly different time in VMs is actually a good thing for privacy. In addition to Whonix using its own time synchronization mechanism, it should actually improve privacy (sys-net and others have slightly different time than dom0, so even if dom0 time is leaked, it's hard to link it with any timestamp leaked through clearnet connections).
|
Does it happen after system suspend? That may cause
But how that would lead to privacy problems? AFAIR you've told that slightly different time in VMs is actually a good thing for privacy. In addition to Whonix using its own time synchronization mechanism, it should actually improve privacy ( |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Jun 5, 2016
Member
Marek Marczykowski-Górecki:
Does it happen after system suspend?
No system suspend involved. (I personally use this almost never except
for testing.)
AFAIR you've told that slightly different time in VMs is actually a good thing for privacy.
In addition to Whonix using its own time synchronization mechanism, it should actually improve privacy
Yes, but 1) and 2) both require a functional VM clock to begin with. If
it jumps arbitrarily due to xen / linux kernel issues, then it cannot work.
But how that would lead to privacy problems?
sdwdate has a certain range of accuracy. While I am experiencing only
small skews, I was reporting this bug, because I guess it could also
lead to huge jumps as described in #1779. Such jumps would be outside
the usual accuracy of sdwdate, hence stand out from others. And such big
jumps can also disrupt connectivity (Tor needs a reasonable correct
clock otherwise it fails to operate...) as described in #1779.
|
Marek Marczykowski-Górecki:
No system suspend involved. (I personally use this almost never except
Yes, but 1) and 2) both require a functional VM clock to begin with. If
sdwdate has a certain range of accuracy. While I am experiencing only |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Jun 5, 2016
Member
Yes, but 1) and 2) both require a functional VM clock to begin with. If it jumps arbitrarily due to xen / linux kernel issues, then it cannot work.
The message you've included shouldn't result in huge clock jumps. Pausing a VM (including system suspend) without synchronizing the clock afterwards will. But it is unrelated situation.
The message you've included shouldn't result in huge clock jumps. Pausing a VM (including system suspend) without synchronizing the clock afterwards will. But it is unrelated situation. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
I see.
|
adrelanos commentedJun 3, 2016
Qubes OS version (e.g.,
R3.1):R3.1
Affected TemplateVMs (e.g.,
fedora-23, if applicable):debian-8, Fedora-23, Whonix 13, probably every template
Actual behavior:
A two seconds time draft. (VM clock is two seconds faster.)
Does not always happen. If I spot this in one already running VM, I spot this in any already running VM that I test.
Full dmesg attached below.
Expected behavior:
None of this should be happening.
Steps to reproduce the behavior:
No cause / effect witnessed yet. Please run
dmesg | grep clockin your AppVMs every now and then (on various computers). If we are lucky you will be able to reproduce it yourself.General notes:
Impact: Anonymity / Whonix is affected by this bug. Might break connectivity for some users. (#1779) On my systems, I witnessed only small skews yet, but for other users it may be much bigger and therefore causing Tor connection interruptions. Possibly also worsening privacy / fingerprinting.
Related issues:
#1779