Should two-digit years be fatal to a refclock?

[Eric S. Raymond]

Mark: Heads up!  Policy question ahead.

Some of our remaining refclocks return only 2-digit years, relying on
the system clock to disambiguate the century.

On conventional PCs this is seldom a problem.  There's a time value
returned by an RTC (real-time clock) which the kernel reads, and
changes when the system time is set. You don't generally see PCs
coming up with the time of their last shutdown because PCs have a coin
battery or supercap associated with the RTC; it uses that alternate
power to update RTC time even while the machine is off.

But some systems don't have RTCs.  The Raspberry Pi is a well-known
current example. So is the BeagleBone.  In general you can't count
on hobby boards or embedded systems to have an RTC.

This Stack Overflow answer

https://raspberrypi.stackexchange.com/questions/4370/where-does-the-raspberry-pi-get-the-time-from

confirms that RPi needs NTP to properly set its system time after
boot.

(I thought the RasPi stored a timestamp on a clean shutdown, then
reads it back at boot time, so time is usually not actually
zeroed. But I don't know that, and no such fallback is mentioned aty
that link.)

None of this, either about systems with RTCs or without, is well
documented.  Web searches don't give good hits when I try to verify my
deductions and guesses.  One reason I'm posting is because I think
it's pretty likely one of our devs has more definite knowledge than I
do.

If you do, speak up, because I would like to add a section to the Time
Servce HOWTO making these things clear.

Now let's consider the worst case. Suppose you either have no RTC or
the RTC's counter somehow gets zeroed.  If you have no RTC your Unix
system may well think it is time_t 0, 1970-01-01T00:00:00.  If you
have an RTC it may zero to some later date, when the RTC was taped out.

If the zero date was in the last century and your local refclock only
ships a two-digit date, you have a problem. NTP will cheerfully
"correct" the time into the last century.  This is a real problem
case with RasPis or BeagleBones using a vanilla NMEA GPS.  So much
for standalone operation, which we now advertise as an NTPsec feature.

Whether NTP will ever recover from this by talking to a peer becomes
questionable.  In theory it should as long as we are within a certain
timespan of its internal pivot date, but I've looked at the code to do
that and it makes my head hurt.  I don't *trust* code that makes my
head hurt.

These considerations raise a question: Should we delete all refclocks
that could tip a system into century failure?

This was never a sensible question to ask about Classic, because
it actually *discarded* the century part of dates.  I fixed that
in our codebase some time back.  That's why we don't strictly speaking
*need* peers any more and can run standalone connected to a GPS with
a good skyview.

Here are refclocks ones in our inventory that return 2-digit years. All but
the last were manufactured in the last century.  All are already
deprecated.

    Generic Spectracom Receivers
    TrueTime GPS/GOES Receivers
    Arbiter 1088A/B GPS Receiver
    Motorola UT Oncore GPS
    NeoClock4X DCF77 / TDF Receiver

Some modes of the generic driver may have this problem as well. A GPS
that doesn't ship GPZDA will, too.  There are options.  It's possible to
detect unambiguously whether a GPS ships GZDA -  we could, in theory,
log a fatal error when we don't get one within two seconds of fix.

I suggest whether these should stay or go depends on how we trade off
not pissing off time grognards running old hardware against the kinds
of correctness guarantee we want to proffer.

We're holding ourselves out as shipping hardened code that is highly
trustable from a security POV.  While I'd be a fool to expect we'll
never have another CVE, we've done a pretty good job of keeping
that promise so far.  No CVEs of our own, and we've dodged over 75%
of Classic's since the fork.

We've already disqualified several refclocks for requiring
proprietary firmware blobs.

How hard-nosed so we want to be about disqualifying dodgy time
sources?

The position we *could* take, which I admit I'm attracted to, is this:

NTP is not a dorm-room project, it's vital infrastructure for
life-critical systems. It's 2019 and decent refclocks are cheap, so the
cost of having to upgrade yours to work with NTPsec is low. We think
it's our actual *duty* to close off as many wacky failure cases as
we can, even if that costs you $80 for a GPZDA-emitting GPS.

Please discuss.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Vegetables are not food; vegetables are what food eats.
Fruit are vegetables that fool you by tasting good.
Fish are fast-moving vegetables.
Mushrooms are what grows on vegetables when food's done with them.
                -- Meat Eater's Credo