adjfreq(2): limit adjustment to [-500000, +500000] ppm

When we recompute the scaling factor during tc_windup() there is an
opportunity for arithmetic overflow if the active timecounter's
adjfreq(2) adjustment is too large.  If we limit the adjustment to
[-500000, +500000] ppm the statement in question cannot overflow.

In particular, we are concerned with the following bit of code:

	scale = (u_int64_t)1 << 63;
	scale += \
	    ((th->th_adjustment + th->th_counter->tc_freq_adj) / 1024) * 2199;
	scale /= th->th_counter->tc_frequency;
	th->th_scale = scale * 2;

where scale is an int64_t.  Overflow when we do:

	scale += (...) / 1024 * 2199;

as th->th_counter->tc_freq_adj is currently unbounded.
th->th_adjustment is limited to [-5000ppm, 5000ppm].

To see that overflow is prevented with the new bounds, consider the
new edge case where th->th_counter->tc_freq_adj is 500000ppm and
th->th_adjustment is 5000ppm.  Both are of type int64_t.  We have:

   int64_t th_adjustment = (5000 * 1000) << 32;	/* 21474836480000000 */
   int64_t tc_freq_adj = 500000000LL << 32;	/* 2147483648000000000 */


   scale = (u_int64_t)1 << 63;			/* 9223372036854775808 */
   scale += (th_adjustment + tc_freq_adj) / 1024 * 2199;
/* scale += 2168958484480000000 / 1024 * 2199; */
/* scale += 4657753620480000000; */

9223372036854775808 + 4657753620480000000 = 13881125657334775808,
which less than 18446744073709551616, so we don't have overflow.

On the opposite end, if th->th_counter->tc_freq_adj is -500000ppm and
th->th_adjustment is -5000ppm we would have -4657753620480000000.

9223372036854775808 - 4657753620480000000 = 4565618416374775808.
Again, no overflow.

500000ppm and -500000ppm are extreme adjustments.  otto@ says ntpd(8)
would never arrive at them naturally, so we are not at risk of breaking
a working setup by imposing these restrictions.

Documentation input from kettenis@.

No complaints from otto@.

0 files changed, 0 insertions, 0 deletions