Re: unable to set time very far in the future

[RVP <rvp%SDF.ORG@localhost>]

On Sun, 16 Oct 2022, Jan Schaumann wrote:

> Do we have examples of what this "unreasonable system
> behaviour" might be,

From the commit message[1]:

---
kern_time: prevent the system clock from being set too low or high

currently doing this will drive KUBSAN haywire and possibly cause
system lock-ups, so more testing should probably be performed before
we let the clock be set too many thousands of years into the future.

ditto for negative values, which were being passed by chrony for
some reason while my internet connection was being unreliable.
this also triggered some interesting KUBSAN reports.
---

> and how we ended up picking this particular value?

Punting to nia@...

The prev. check[2] was for MAX_INT - 1 year.

> Absent any functional change, could we factor this out to a #define
> for future code spelunkers?
>
> Possibly switching to a more human friendly number such as 4000AD (or
> 4004AD if we port NetBSD to the spindizzy)

You mean like FreeBSD? In sys/kern/kern_time.c:

    398 static int allow_insane_settime = 0;
    399 SYSCTL_INT(_debug, OID_AUTO, allow_insane_settime, CTLFLAG_RWTUN,
    400     &allow_insane_settime, 0,
    401     "do not perform possibly restrictive checks on settime(2) args");
    402
    403 int
    404 kern_clock_settime(struct thread *td, clockid_t clock_id, struct timespec *ats)
    405 {
    406         struct timeval atv;
    407         int error;
    408
    409         if ((error = priv_check(td, PRIV_CLOCK_SETTIME)) != 0)
    410                 return (error);
    411         if (clock_id != CLOCK_REALTIME)
    412                 return (EINVAL);
    413         if (ats->tv_nsec < 0 || ats->tv_nsec >= NS_PER_SEC || ats->tv_sec < 0)
    414                 return (EINVAL);
    415         if (!allow_insane_settime &&
    416             (ats->tv_sec > 8000ULL * 365 * 24 * 60 * 60 ||
    417             ats->tv_sec < utc_offset()))
    418                 return (EINVAL);


8000 * 365 * 24 * 60 * 60 secs. gives a GMT time of:

Wed Sep  9 00:00:00 9964

which is 1970 + 8000 - 1940 leap days. Not an easily remembered date either :)...

-RVP

[1]: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/kern_time.c.diff?r1=1.205&r2=1.206&only_with_tag=MAIN
[2]: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/kern_time.c.diff?r1=1.97&r2=1.98&only_with_tag=MAIN