On Mon, 31 Aug 1998, Andy Church wrote: > >Andy Church <achurchat_private> wrote: > >> One way I could see to > >> make this more effective would be to use 64-bit times and disallow both > >> setting the clock back and changing the top 2 bits to anything other than > >> zero. This would break the rollover attack without causing any premature > >> Y2k-like problems (2^62 seconds ~= 10^13 years). > > > >This is still a DOS of sorts, as you can set the clock to 2^62-1, and > >then it will be impossible to return the clock to the correct time > >without rebooting. Many things will probably be unhappy to find > >themselves 10^13 years in the future. > > Good point; I obviously hadn't thought that far. I suppose you could > just not let the clock be set at all--that would pretty cleanly stop > clock-setting problems. (: > > Come to think of it, aside from adjusting for clock drift, there > shouldn't be any need to set the system clock under normal circumstances. > If there were a system call like adjtime() which set a _continuous_ (not > one-time) drift adjustment--for example, telling the kernel to adjust > forward or backward one second every N seconds--then you could set that > (and maybe the clock as well) at boot time, then disallow all clock > adjustment functions, and you should be okay. Linux looks like it has an > adjtimex() that works something like this, though I don't have a man page > for it. The issue of drift correction is important, however the gradual change technique employed in Linux adjtimex() is a constant one designed to make up for inexactness in the system's ability to keep time. Another, separate problem is the issue of arbitrary drift caused by console messages. It is my understanding that some unices turn off all interrupts when dumping messages to the console and as such can cause the timer to miss a beat. Such is the reason for timed and many other collaborative clock management daemons. I would propose a more subtle mechanism where the system could be told to gain or lose a certain number of seconds, but with an inbuilt maximum rate of change (say one second every minute). This would allow for gradual corrections that are arbitrary on top of a system for guarding against constant drift. "I need to make up 13 seconds." -> timetrim( 13 ). This could all be layered on top of the existing Linux adjtimex however I don't know what the limits of it are (i.e. could you make a system gain an hour every second). You would also need some method for re-setting the time adjustment back to the 'no adjustment' adjustment when the desired change has been made. C=) -------------------------------------------------------------------------- There is hardly a thing in the world that some man can not make a little worse and sell a little cheaper. -------------------------------------------------------------------------- Caskey <caskey*technocage.com> /// pager.818.698.2306 TechnoCage Inc. ///| gpg: 1024D/7BBB1485 -------------------------------------------------------------------------- I didn't fight my way to the top of the food chain to be a vegetarian.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:14:36 PDT