Loadable Refclock Drivers

ntpd has traditionally used statically-linked reference clock drivers. While this means that the executable is more tamper-proof, it also means the size and functionality of the executable is determined at compile-time.

Dave Mills wants to limit the addition of new drivers to the distribution as many consider the current fully-configured executable to be "too big".

Harlan believes that there are some potential problems with traditional loadable modules:

• they are an easy way to "infect" a system, especially if ntpd is running as root.
• the codebase is currently extremely portable, even to fairly old hardware and OSes. There are still a very useful number of systems that do not support dlopen() and friends.

Harlan further believes that it should be possible to provide a lightweight "refclock processing language" that would provide a relatively safe way to interface with a reference clock, perform the required manipulation of the data, and send the results to refclock_process() and friends.

Since Harlan is also fond of saying that there needs to be "sufficient" mechanism to provide the needed functionality, and that mechanism should be sufficiently robust to support a variety of different policy choices, the following is proposed.

Ways to provide refclock drivers

• static
  • native refclock driver executables
  • API to a refclock processing language
• dynamically loaded
  • native refclock driver executables
  • API to a refclock processing language

The API to a refclock processing language could include:

• forth
• lisp
• java
• python
• tcl

just to name a few.

Related Topics: http://sourceware.org/libffi/

---

Please edit above or comment below, as appropriate.

-- HarlanStenn - 01 Jul 2005

---

It is correct that there is an increased risk when using dloaded modules. So the modules should be picked up from a fixed or configured directory, not via LD_LIRARY_PATH. This reduces the risk somewhat. Additionally a permission sanitiy check such as in sendmail for accessing trusted files could be used.

As for portability I read the ltdl documentation and the libtool support from the GNU autoconfig suite. Currently I have the impression that these tools could help around the concerns about portability mentioned above. On platforms which don't support dloading it will statically link the required files. ltdl is an abstraction from the actual dloading mechanism and seems to be a way to keep the code from being infected with the portability-#ifdef disease.

The idea of using a well known scripting langugage looks charming at first. But I think there are some drawbacks:

• only forth, lisp stand a chance of having a reasonably small interpreter footprint
• python, java, tcl are bigger citizens.
• The (memory) resource model of scripting languages may be not appropriate for a long running daemon.
• Mechanisms such as garbage collection are not suitable for a near real time application. This is especially problemetatic as GC usually happens at the most inconvienient time. Given that and that ntpd has SIGIO blocked during refclock/protocol processing we might be incuring significant and uncontrollable delays during ntpd operation.
• (dynamic) memory usage should be kept to a minimum. The current drivers are faily reasonable in that respect
• Almost all scripting languages would need to be extended by an API to access internals of the NTP core engine. There are quite a few variables that refclock_drivers like to twiddle with.
• If we use a scripting language we would also need to re-implement and re-validate the refclocks.
• With a scripting language we also import a maintenance risk as we would have to track the scripting implementation for bug and security fixes.

Seeing the list above I get the impression that trying to use ltdl with the current native refclocks is quite a bit less work and risk and it preserves the current value of the refclocks. Converting the current refclocks to dloadable ones is a fairly straighforward process, especially if ltdl lives up to its promises.

Comment ? More ideas ?

-- FrankKardel - 01 Jul 2005

---

My point about many different potential scripting languages was that once we supported one scripting language the mechanism would be in place to support others. The choice of which ones to use (or not) would become a policy choice. It would also be much easier to test and compare different scripting languages.

As for the GC issues, I wonder if we could use the SHM refclock to solve this issue. In this case the actual refclock code would be running in a different process and the information would simply be passed to ntpd via the shm interface.

-- HarlanStenn - 01 Jul 2005

---

At least for the critical part of timestamping clock messages I am not too certain that scripting languages with possible GC risks are suitable for that. Processing the data formats is not so complicated that we could benefit from the advantages of the scripting languages. And we would need some good interfaces for tty setup, precision time stamping (clock_gettime() at minimum) and possibly SHM access. Not all scripting languages fill that bill easily. Java 1.4 for example gives you just milli second resolution. This would not be usable for us. Java 1.5 is better in that respect.

Running an additional process will get us some protection of the main daemon, but at the expense of shm resources, additional task switches, possible re-implementation of existing concepts (io, filtering, conversion come to mind right now) and loss of functionality unless we seriously vamp up the SHM interface including but not limited to bidirectional communication if we are keeping up the practice of configuration via mode 7 messages.

-- FrankKardel - 01 Jul 2005

---

One of the provided "functions" should be PPSAPI support, that should include serial number checking. If we detect that the device does not properly implement serial numbers, we should squawk (once) and then continue with a full timestamp check to catch duplicated samples.

-- HarlanStenn - 2011-03-17