>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. --Andy Church | If Bell Atlantic really is the heart achurchat_private | of communication, then it desperately www.dragonfire.net/~achurch/ | needs a quadruple bypass.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:14:30 PDT