In message <Pine.NEB.4.33.0107311133510.340-100000@candlekeep.home-net.internet
connect.net>Bill Studenmund writes
>On Tue, 31 Jul 2001, Emmanuel Dreyfus wrote:


>Also, say there are times when ntpd NEEDS to set the date back (like say
>there's a network outage, and the clock has drifted forward & needs to be
>scooted back). Preventing ntpd from moving the clock back can, in such a
>case, make it unable to do its job. So systems which need the clock set
>right will fail.

Or multibooting between a timezone-aware and non-timezone-aware OS.

>So I think that as long as ntpd is able to do _anything_ with the system
>clock, an ntpd vulnerability can be a security vulnerability in an
>environment where time is used for replay protection.

yep.

>Let me repeat myself though. I _do_ think making a /dev/clock is a good
>thing. It will take the scope of ntpd vulnerabilites from the realm of a
>compromised root daemon to the realm of a compromised system clock. 

[...]

Why not check with Dave Mills and Harlan Stenn, and see what they
think of the idea? And ask how it would fit with Dave's "nanokernel"
(an inkernel, nanosecond resolution, SMP-aware implementation of the
NTP pll); what (if any) the timing implications of changing the API;
and whether the UDel folks want to buy the changes back?