linux-kernel - Re: [PATCH] timekeeping: Prevent coarse clocks going backwards

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] [day] [month] [year] [list]

Message-ID: <CANDhNCr21HXQOqfhcJFM6x7pNHCevSEKdg2_jz7KbLj=g8+0Sg@mail.gmail.com>
Date: Fri, 18 Apr 2025 22:55:45 -0700
From: John Stultz <jstultz@...gle.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Miroslav Lichvar <mlichvar@...hat.com>, LKML <linux-kernel@...r.kernel.org>, 
	Stephen Boyd <sboyd@...nel.org>, Anna-Maria Behnsen <anna-maria@...utronix.de>, 
	Frederic Weisbecker <frederic@...nel.org>, Shuah Khan <shuah@...nel.org>, linux-kselftest@...r.kernel.org, 
	kernel-team@...roid.com, Lei Chen <lei.chen@...rtx.com>
Subject: Re: [PATCH] timekeeping: Prevent coarse clocks going backwards

On Fri, Apr 18, 2025 at 12:00 AM Thomas Gleixner <tglx@...utronix.de> wrote:
> On Fri, Apr 18 2025 at 08:37, Thomas Gleixner wrote:
> > On Thu, Apr 17 2025 at 17:46, John Stultz wrote:
> >> Instead it seems like we should just do:
> >>   tk->coarse_nsec = tk->tkr_mono.xtime_nsec >> tk->tkr_mono.shift;
> >
> > You end up with the same problem again because xtime_nsec can move
> > backwards when the multiplier is updated, no?
>
> Something like the below should work.

Hey Thomas,
  So I did test this version (I'll call it v2) of the patch and it
does avoid the problem I was seeing earlier with your first patch.

Though I also just sent my own slight rework of your patch
(https://lore.kernel.org/lkml/20250419054706.2319105-1-jstultz@google.com/).
The main difference with my version is just the avoidance of mid-tick
updates to the coarse clock by adjtime calls (and the slight benefit
of avoiding the mult in the update path, but this is probably minor).

It's done ok in my testing so far, but obviously the effects of these
changes can be subtle.

I'm ok with either approach, so let me know what you'd prefer.
For your version:
  Acked-by: John Stultz <jstultz@...gle.com>

thanks
-john