Driver strategy - we need to decide among incompatible goals

[Eric S. Raymond]

Achim Gratz via devel <devel at ntpsec.org>:
> Eric S. Raymond via devel writes:
> > 2. Remove support for device classes that pose an unacceptable
> > security risk, e.g. by requiring proprietary binary blobs to be 
> > linked to the kernel.
> 
> There never were any drivers that required "proprietary binary blobs" in
> (x)ntpd that I can remember.  That is unless you count firmware on the
> clocks, in which case you'd need to throw out all current GPS support as
> well.

You've forgotten much, then. I remind you of the Type 2 Bancomm, the
Type 45 Spectracom TSync PCI, and the Type 16 Bancomm GPS/IRIG
Receiver.

> > I wrote about this bit of history because it's a precedent for
> > narrowing our hardware support in order to improve our security
> > and reduce our expected downstream defect rate.
> 
> Before you start to go down that road remind us again what threat model
> you are trying to protect against.  Any talk about security is hollow
> theater without that bit of information.

Whatever your threat model is, reducing attack surface is effective
security hardening.  Reducing total LOC and complexity in the codebase
reduces attack surface.  Thus, reducing LOC anywhere you can do it 
is a hardening strategy.

If you're only just now noticing that this is NTPsec development's
central thrust, and has been since 2015, and that judging by CVEs in
Classic that we've evaded it has been rather spectacularly successful,
maybe you ought to be paying closer attention to what we're actually
doing and achieving before you criticize.

> > NTPsec aims to be highly secure and reliable.  If we're serious about
> > that, we need to reduce our vulnerability to defects from these
> > wraparound/rollover problems. 
> 
> You won't make even a tiny step in that direction based on your current
> understanding of the issues.

Please read https://docs.ntpsec.org/latest/rollover.html so you won't 
be under any misapprehensions about what we understand.  You might
also want to read the big comment at  

https://gitlab.com/gpsd/gpsd/blob/master/timebase.c

You can see from that how firm a grasp Gary Miller and I had on these
problems before NTPsec.

Yes, in the presence of era wraparounds perfect resolution of absolute time
is not possible. We're not under any illusion that it is. What  *is* 
achievable to to reduce the complexity of the failure cases and make the
code better at self-auditing and notifying a human when it enters a bad 
state.

Generally speaking, you can tell improvement of this kind is happening
any time you rip out old shims.  The code that prevented autonomous
operation from working at all before I fixed it in 2017 was, I believe,
an old shim from the early days of the Y2K panic.

> > My thinking was that we would eventually drop all of the 2-digit-only
> > modes and drivers, and say "if your refclock doesn't ship 4-digit
> > years, it's disqualified".  Besides the autonomy issue, devices with
> > this quirk are often very old hardware with wraparound problems.
> 
> So, all GPS receivers, to start with? 

No, but it is conceivable that we might someday disqualify NMEA receivers
that don't ship a ZDA sentence.

Yes, of course the ZDA payload will be wrong after a wraparound. By
removing the kludges that try to deduce a century from a two-digit
year, though, we'd make the code to detect failure cases easier to
reason about and be able to assert stronger invarients.

You don't get to a clock that never breaks this way.  You *do* get to
an ntpd that is less likely to fuck up in some obscure way (even when
the hardware is sane) because of unintended effects of shims and
crocks added to support 2-digit years.

> > Now we have a request to remove the deprecation marker from the Oncore
> > driver. The Oncore product line is EOL, but we are told there are 
> > receivers still in production that can use this driver.
> 
> Would it surprise you to hear that while the Oncore receivers aren't
> available anymore, there are (at least used to be) more modern receivers
> that behave like one?  Ditto for the Motorola M12 and other "classic"
> GPS.

Not surprised at all.  In fact, that news was in issue #608.

The question is *whether we ought to give a shit* about modern hardware
that emulates an Oncore or an M12.  If you start from the assumption that
our highest priority is nursemaiding crufty old designs and cufty old
clock protocols, then maybe you'll never see beyond that assumption.

On the other hand, if you grasp that modern primary clocks are *not
expensive*, then maybe you start seeing support for that old hardware
as a source of technical debt that should be cleared.

> How about an option 4. where you admit that full autonomy not only is
> provably impossible to result in an absolute time with bounded error
> margin, but also not even interesting to NTP.  That might get you to
> recognize that the only way to synchronize to some notationally correct
> time is to use as many _independent_ sources of time as you can get hold
> of.

Fine, we agree on that.  But there's no rule that says any of those 
multiple sources must be a network peer, and important deployment cases 
in which you'd like them to be (say) GPSes watching three different
constellations with two rubidium clocks for holddover/backup.

Classic couldn't handle that case.  NTPsec *can*.  And there's room forv 
more improvement in that area.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>