linux-kernel - Introduce clock precision to help time travelers was Re: Extreme time jitter with suspend/resume cycles

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171015063738.GA24716@xo-6d-61-c0.localdomain>
Date:   Sun, 15 Oct 2017 08:39:26 +0200
From:   Pavel Machek <pavel@....cz>
To:     Gabriel Beddingfield <gabe@...tlabs.com>, pavel@....cz
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        John Stultz <john.stultz@...aro.org>,
        Alessandro Zummo <a.zummo@...ertech.it>,
        Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
        linux-rtc@...r.kernel.org, Guy Erb <guy@...tlabs.com>,
        hharte@...tlabs.com
Subject: Introduce clock precision to help time travelers was Re: Extreme
 time jitter with suspend/resume cycles

H!

> We have been developing a device that has very a very aggressive power
> policy, doing suspend/resume cycles a few times a minute ("echo mem >
> /sys/power/state"). In doing so, we found that the system time
> experiences a lot of jitter (compared to, say, an NTP server). It was
> not uncommon for us to see time corrections of 1s to 4s on a regular
> basis. This didn't happen when the device stayed awake, only when it
> was allowed to do suspend/resume.

Ok, so I have various machines here. It seems only about half of them has
working RTC. That are the boring ones.

And even the boring ones have pretty imprecise RTCs... For example Nokia N9.
I only power it up from time to time, I believe it drifts something like
minute per month... For normal use with SIM card, it can probably correct
from GSM network if you happen to have a cell phone signal, but...

More interesting machines... Old thinkpad is running without CMOS battery.
ARM OLPC has _three_ RTCs, but not a single working one. N900 has working
RTC but no or dead backup battery. On these, RTC driver probably knows
time is not valid, but feeds the garbage into the system time, anyway. Ouch.
Neither Sharp Zaurus SL-5500 nor C-3000 had battery backup on RTC...

Even in new end-user machines, time quality varies a lot. "First boot, please
enter time" is only accurate to seconds, if the user is careful. RTC is usually
not very accurate, either... and noone uses adjtime these days. GSM time and
ntpdate are probably accurate to miliseconds, GPS can provide time down to
picoseconds... And broken systems are so common "swclock" is available in
init system to store time in file, so it at least does not go backwards.

https (and other crypto) depends on time... so it is important to know approximate
month we are in.

Is it time we handle it better?

Could we return both time and log2(expected error) from system calls?

That way we could hide the clock in GUI if time is not available or not precise
to minutes, ignore certificate dates when time is not precise to months, and
you would not have to send me a "Pavel, are you time traveling, again?" message
next time my mailer sends email dated to 1970.

									Pavel

PS: And yes, I'm time-travaling again, this time by ~15 hours.