linux-kernel - Re: Time keeping while suspended in the presence of persistent clock drift

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: <b074f506-2568-4506-9557-4a9bc9cbea83@www.fastmail.com>
Date:   Thu, 09 Dec 2021 11:06:42 -0700
From:   "Joel Daniels" <jdaniels@...t.com>
To:     "John Stultz" <john.stultz@...aro.org>,
        "Thomas Gleixner" <tglx@...utronix.de>,
        "Stephen Boyd" <sboyd@...nel.org>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: Time keeping while suspended in the presence of persistent clock drift

My email client just stripped all the newlines from my message making
it unreadable. I apologize and am resending it using a different
client. The original message (properly wrapped) is below.

=========

Hi,

I have an x86 laptop whose CMOS (RTC) clock gains an extra 3.75 seconds
per day that it is suspended (S3) or off. It keeps time quite accurately
while awake using the TSC clock source. I use the machine about 1 hour
per day with the machine in the S3 sleep state for the remaining 23
hours.

The machine is not usually connected to a network and I do not run an
NTP daemon (though I do not believe this is relevant). When cold
booting, I correct for the CMOS clock drift using hwclock before making
the filesystem writable. When resuming from suspend-to-ram (S3),
however, I must either use hwclock again (causing the system time to
jump backwards and potentially upsetting programs like make) or use a
large slew rate (absolute value greater than 1000 PPM) to correct the
system clock.

As far as I can tell there is currently no way to inform the kernel of
my CMOS clock drift. Is this correct?

I am considering writing a patch to make the kernel compensate for the
drift of the persistent and/or RTC clock(s) when injecting sleep time.
The patch would require user space to inform the kernel of the drift
(probably via sysfs). Does this seem like a good approach?

Regards,
Joel Daniels