Received-SPF: pass (google.com: domain of linux-kernel+bounces-172240-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Tue, 7 May 2024 22:03:18 +0000
From: Justin Stitt <justinstitt@google.com>
To: John Stultz <jstultz@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>, Stephen Boyd <sboyd@kernel.org>, 
	Nathan Chancellor <nathan@kernel.org>, Bill Wendling <morbo@google.com>, linux-kernel@vger.kernel.org, 
	llvm@lists.linux.dev
Subject: Re: [PATCH] ntp: safeguard against time_constant overflow case
Message-ID: <zhb5dy6ysbdghj3vhnj2s3gd7fhqg3v7xmhonkgfxp33qtc6bw@pqyhntprkwjr>
References: <20240506-b4-sio-ntp-c-v1-1-a01281aa01ba@google.com>
 <CANDhNCps8qE1a+Vp2HNgU=-vA5RwhrLd2_D0EMZiNv1j_OOYWA@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CANDhNCps8qE1a+Vp2HNgU=-vA5RwhrLd2_D0EMZiNv1j_OOYWA@mail.gmail.com>

Hi,

On Mon, May 06, 2024 at 11:02:17PM -0700, John Stultz wrote:
> On Mon, May 6, 2024 at 3:01 PM Justin Stitt <justinstitt@google.com> wrote:
> >
> > Nonetheless, let's slightly rework the logic surrounding time_constant
> > and how it is incremented such that we avoid unintentional wrap-around
> > (even though it is extremely unlikely to be hit in non-fuzzing scenarios).
> >
> > [1]: https://github.com/llvm/llvm-project/pull/82432
> >
> > Signed-off-by: Justin Stitt <justinstitt@google.com>
> > ---
> >  kernel/time/ntp.c | 11 +++++++----
> >  1 file changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
> > index 406dccb79c2b..a9f039601968 100644
> > --- a/kernel/time/ntp.c
> > +++ b/kernel/time/ntp.c
> > @@ -65,6 +65,9 @@ static s64                    time_offset;
> >  /* pll time constant:                                                  */
> >  static long                    time_constant = 2;
> >
> > +/* pll time constant increment:                                                */
> > +static long                    time_constant_inc = 4;
> > +
> 
> I'd probably use a `#define TIME_CONSTANT_INC 4` for this.
> 
> >  /* maximum error (usecs):                                              */
> >  static long                    time_maxerror = NTP_PHASE_LIMIT;
> >
> > @@ -734,10 +737,10 @@ static inline void process_adjtimex_modes(const struct __kernel_timex *txc,
> >
> >         if (txc->modes & ADJ_TIMECONST) {
> >                 time_constant = txc->constant;
> > -               if (!(time_status & STA_NANO))
> > -                       time_constant += 4;
> > -               time_constant = min(time_constant, (long)MAXTC);
> > -               time_constant = max(time_constant, 0l);
> > +               if (!(time_status & STA_NANO) &&
> > +                   unlikely(LONG_MAX - time_constant_inc >= time_constant))
> > +                       time_constant += time_constant_inc;
> > +               time_constant = clamp_t(long, time_constant, 0, MAXTC);
> >         }
> 
> Overall, this looks fine. Though the time_status conditional is now a
> little unwieldy.
> 
> I wonder if some sort of a helper like:
>       time_constant = safe_add(time_constant, TIME_CONSTANT_INC, LONG_MAX);
> 
> Might make this a little easier to read?

How about something like this:

	if (txc->modes & ADJ_TIMECONST) {
		if (!(time_status & STA_NANO))
			time_constant = clamp_t(long, txc->constant,
						-TIME_CONSTANT_INC,
						MAXTC - TIME_CONSTANT_INC) +
						TIME_CONSTANT_INC;
		else
			time_constant = clamp_t(long, txc->constant, 0, MAXTC);
	}

We can remove the initial assignment and use some fancy clamps.

> 
> thanks
> -john

Thanks
Justin