ntpq, refclocks

[Eric S. Raymond]

Hal Murray via devel <devel at ntpsec.org>:
> 
> Does anybody have any good ideas on a modern way to handle ntpq/mode 6?
> 
> Background...
> 
> We could split the server side out into a separate process.  That leaves a 
> very tiny attack surface from the network.  I think I could do that now except 
> for mode 6.
> 
> Does anybody have any good ideas on how to replace the current ntpq 
> functionality?
> 
> Handwave.  My straw man would be to put all the counters into shared memory.  
> Then a local-only version of ntpq seems reasonable.  If SSH isn't good enough, 
> we could add a TCP or TLS wrapper.

This is probably achievable.  But...

Any reason not to use Unix-domain sockets and just reuse the current
protcol handling, except it's not accessible netwide?  That might be simpler.

> I also want to be able to quickly add more counters.  That gets into a version 
> control tangle.  Would it work to have 2 version numbers?  (maybe call them 
> version and sub-version)  One for the base/stable counters and another for the 
> new/experimental ones?  The idea is that the new ones get folded into the base 
> at release time.

I'd have no objection to that.

> Similarly, it would be nice to split the refclocks out into a separate 
> process.

I looked at that prospect pretty closely years ago.  Here's why it dodn't happen:

How you handle configuration for separate refclockd and ntpnetd
turns out to be a nasty tangle.  Do they both replicate the entire
config parser and parse the same config file, ignoroong the bits
they don't need?  Or do you split the config and suffer a flag day?

It's hard to know what the right thing is here.  Going with a unitary
parser preserves backward compability, but one of the project gols is
to reduce attack surface to the dead minimum possible and we certainly
would not be accomplishing *that* with a unitary parser.

Another problem is that throwing out the obsolete drivers has
drastically reduced the expected gain from splitting the daemon.  When
the drivers were a huge mass of code that dwarfed the networking part,
splitting them out and adding a thin refclockd wrapper around them
made obvious sense.  Now they're only 24KLOC total and the wrapper
around them would be a significant fraction of that as a LOC
*increase*.

I reluctantly concluded that the effort wasn't justified.  I'm
open to argument on that.

> We need something better than the current shared memory approach.  
> Read only SHM would be OK for data, but we need a clean way to wake up the 
> receiving side so it can process the data promptly.

I'd like to hear more about this.  It sounds like a separate issue from
the damon split.

> More background...
> 
> I'd like to move the current kernel mode PLL to user space.  I think modern 
> CPUs are fast enough for that to make sense.  I haven't done any 
> experimentation.

Can't really respond to this as I don't understand the kernel PLL.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>