linux-kernel - Re: [PATCH v2] ntp: Make sure RTC is synchronized for any time jump

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: <87zfmm28xz.ffs@tglx>
Date: Tue, 29 Oct 2024 17:03:04 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Benjamin ROBIN <dev@...jarobin.fr>, jstultz@...gle.com
Cc: sboyd@...nel.org, linux-kernel@...r.kernel.org, Benjamin ROBIN
 <dev@...jarobin.fr>
Subject: Re: [PATCH v2] ntp: Make sure RTC is synchronized for any time jump

On Sun, Oct 27 2024 at 18:43, Benjamin ROBIN wrote:
> Follow-up of commit 35b603f8a78b ("ntp: Make sure RTC is synchronized
> when time goes backwards").
>
> sync_hw_clock() is normally called every 11 minutes when time is
> synchronized. This issue is that this periodic timer uses the REALTIME
> clock, so when time moves backwards, the timer expires late.
>
> If the timer expires late, which can be days later, the RTC will no longer
> be updated, which is an issue if the device is abruptly powered OFF during
> this period. When the device will restart (when powered ON), it will have
> the date prior to the time jump.
>
> This follow-up handles all kernel API (syscall) that can trigger a time
> jump. Cancel periodic timer on any time jump, if and only if STA_UNSYNC
> flag was previously set (net_clear() was called).

This does not parse. previously set means it was set before the
operation. What you want to say here is:

  Cancel the RTC synchronization timer if the operation set the
  STA_UNSYNC flag.

net_clear()? I assume you mean ntp_clear(). But that's not the only way:

  do_adjtimex() can modify STA_UNSYNC via process_adj_status()

Also ADJ_TAI modifies CLOCK_REALTIME, which is why clock_set() is
invoked. That can make CLOCK_REALTIME go backwards.

>  	clock_was_set(CLOCK_SET_WALL);
> +	ntp_notify_cmos_timer(true);

>  	clock_was_set(CLOCK_SET_WALL);
> +	ntp_notify_cmos_timer(true);

>  	clock_was_set(CLOCK_SET_WALL | CLOCK_SET_BOOT);
> +	ntp_notify_cmos_timer(true);

Can we please have a helper function which wraps all of this?

timekeeping_clock_was_set(bases)
{
        clock_was_set(bases);
        if (bases & CLOCK_SET_WALL)
        	ntp_notify_cmos_timer(true);
}

?

> @@ -2714,7 +2715,11 @@ int do_adjtimex(struct __kernel_timex *txc)
>  	if (clock_set)
>  		clock_was_set(CLOCK_SET_WALL);
>  
> -	ntp_notify_cmos_timer(offset_set);
> +	/* Time jump (ADJ_SETOFFSET) is handled by timekeeping_inject_offset(),
> +	 * which calls ntp_notify_cmos_timer() to cancel NTP sync hrtimer.
> +	 * For the rest of do_adjtimex(), NTP sync flag is not cleared, so no
> +	 * need to cancel NTP sync hrtimer here. */

/*
 * Aside of the horrible comment formatting this is wrong as I pointed
 * out above.
 */

The problem here is that ADJ_SETOFFSET is handled seperately. This
really want's all to be in one tk_core.lock held section.

Just split out the inner workings of timekeeping_inject_offset() into a
helper and invoke it under the lock from both places which call it.

Same for timekeeping_advance().

Make sure to move all the audit and randomness muck outside of the
locked region.

That allows to cover ADJ_SETOFFSET and ADJ_TAI, but still fails to take
the modifications of STA_UNSYNC into account, but that's trivial to
solve because you can let do_adjtimex() indicate that change to the
caller.

Then you end up with:

     if (clock_set)
     	timekeeping_clock_was_set(CLOCK_SET_WALL);
     else
     	ntp_notify_cmos_timer(sta_unsync_changed);

or something like that. The latter makes sure that the timer is canceled
when STA_UNSYNC changed. It does not matter whether it was set or
cleared. You always want to cancel.

That obviously needs to be split into several patches, but you get the
idea.

Thanks,

        tglx