[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qubes-devel
Subject:    Re: [qubes-devel] Whonix timesync and host suspend (was: Re: How to set clocksource from xen to tsc?
From:       Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek () invisiblethingslab ! com>
Date:       2016-02-29 15:23:09
Message-ID: 20160229152309.GI25203 () mail-itl
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Feb 25, 2016 at 10:26:46PM +0100, Marek Marczykowski-Górecki wrote:
> On Thu, Feb 25, 2016 at 09:22:11PM +0000, Patrick Schleizer wrote:
> > Marek Marczykowski-Górecki:
> > > On Sat, Feb 20, 2016 at 06:12:25PM +0000, Patrick Schleizer wrote:
> > > > Marek Marczykowski-Górecki:
> > > > > On Wed, Feb 17, 2016 at 10:53:03PM +0000, Patrick Schleizer wrote:
> > > > > > Marek Marczykowski-Górecki:
> > > > > But still VM will be able to switch back to 'xen'.
> > > 
> > > > Right, however just switching to tsc alone is also worthwhile as this
> > > > should help making time correlation attacks harder. It should make the
> > > > VM clock more independent. The clock should be slightly differently
> > > > ticking then, right? Therefore making measurements at the remote
> > > > (javascript time leaks etc) less useful.
> > > 
> > > Ok, IMHO worth doing that from some Whonix-specific startup script.
> > 
> > Experimented with this. Will unfortunately probably not work well. Weird
> > kernel message:
> > 
> > [22559.779482] timekeeping watchdog: Marking clocksource 'tsc' as
> > unstable, because the skew is too large:
> > [22559.779494]  'xen' wd_now: 2745b95736a1 wd_last: 27448e384015 mask:
> > ffffffffffffffff
> > [22559.779498]  'tsc' cs_now: 15e1920f6 cs_last: 2fa7ae81384a mask:
> > ffffffffffffffff
> 
> Did you get this after resume from suspend? Maybe related to
> https://github.com/QubesOS/qubes-issues/issues/1764 ?

It still isn't clear to me if clocksource 'xen' provides absolute
Xen/dom0 timestamp value to the VM. But from the userspace point of view, it
looks like only some counter. Also clocksource 'xen' seems to be a
better choice for solving system suspend issue.

Simple experiment shows that clocksource 'tsc' after host suspend is
totally broken - when VM has is set, VM's clock is frozen after resume
(until clocksource switched to 'xen' - either manually, or automatically
as you've seen above).

But, even with clocksource 'xen', every VM clock seems to be independent
- - if the time was desynchronized before suspend, it is still such after
resume, with the same offset.  With an exception, that it seems like the
VM time was frozen for the time of system sleep.

Not sure if such abstraction is implemented in Xen (which would be
good), or in Linux (which could be bypassed by an attacker with
kernel-level access).

And back to the suspend issue - is it possible for Whonix gateway (and
workstation) to obtain time for itself, without dom0 cooperation? So
only some qrexec call to notify that suspend happened would be enough.
But since tor can't connect with large clock skew (or it can?), I guess
not.

In the later case, dom0 will need to provide slightly randomized time to
the VM. How large that difference needs to be to prevent time
correlations? bootclockrandomization[1] seems to use +/- 180s 
Currently dom0 (in qvm-sync-clock -> qubes.SetDateTime) gives time with
precision up to a second (no milliseconds/nanoseconds). I guess it is
too precise.

Do you have an idea how this should be implemented? I guess there should
be dom0 qrexec service like qubes.GetRandomizedTime, which would give
such randomized time. This service could be called in response to
"system resume" notification from dom0 (as you've already written
somewhere).

BTW why 0-5 is excluded in bootclockrandomization? I think this leaks
some data. For example if attacker have already some selected set of
data to correlate (like "all Tor users in area X"), he/she can easily
further narrow the search by eliminating those with time almost in sync
(+/-5sec). Given popularity of NTP, which (when works) is pretty good at
keeping the time in sync, this allows to easily eliminate all such
users, leaving probably only those using Whonix, or maybe even more
precise correlation...

[1]
https://github.com/Whonix/bootclockrandomization/blob/master/usr/share/bootclockrandomization/start


- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJW1GJcAAoJENuP0xzK19csOdkIAJIJLG2YPjSkCvMggIGFx1Xc
wUmPMnGYxu59rP63qzKcEzf3k5L7IgZbEW3HlZtdWD/GQVYrbJggfZy8gA4v9buS
20AyT6Sg1VnrkLDU8UzF87fGID7zOrxxTnADn+nIINKKb4F6iniHkWaJhA77w2Ne
Cgxq/GFEXBf3okCKcJwY254wXmdPLLe2AugKzR3YuLX9rbFbjHh1g4L4SzFl5w5/
fvPSTUDxDfcHpRWHBQdw4XtXnaIYNG0LV4G4f9TzVatJF7Z441GFiUznbdDqRztW
HAYKN8rQOvcODwGAb3kIuSiseP3HbFAp4Y4ss8o6yZ6rdMNSU9cKJJMkB8L0py0=
=aDr7
-----END PGP SIGNATURE-----

-- 
You received this message because you are subscribed to the Google Groups \
"qubes-devel" group. To unsubscribe from this group and stop receiving emails from \
it, send an email to qubes-devel+unsubscribe@googlegroups.com. To post to this group, \
send email to qubes-devel@googlegroups.com. To view this discussion on the web visit \
https://groups.google.com/d/msgid/qubes-devel/20160229152309.GI25203%40mail-itl. For \
more options, visit https://groups.google.com/d/optout.


[prev in list] [next in list] [prev in thread] [next in thread]