Hal Murray via devel <devel@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>
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
