Fixing clock skew
conrad at apple.com
Wed May 28 02:43:54 EDT 2003
At 12:49 AM -0400 5/28/03, Ben Creech wrote:
>Would you have the user stop the system clock until Father Time catches up?
Perhaps yes, and via adjtime. Anyway, settimeofday on some unixes
doesn't support decreasing the system time, because it is a Bad
>Why, in particular, is it a bad thing?
Data loss. An example I saw was code which depended on modifying two
files and the timestamps reflecting that ordering. If it saw the
second file had an earlier timestamp it took that as an indication
that the previous modification-pair had been interrupted, probably by
a system crash. It went downhill from there.
Event loss. Consider a change detection algorithms which looks for
an increased modification time... retrograde timestamps can let
changes go undetected, potentially forever.
Event replication. Events triggered by an absolute system time may
be triggered a second time, with arbitrary consequences.
>Are you hinting at something security-related?
Like cloaking when a breach happened, to hinder post-mortem analysis?
Or some NTP based attack? Here I'm only guessing.
>Obviously some things will such as make-based
>systems will need to be cleaned, etc, but I will assume that if the
>user clicks "yes" to the dialog box that they're aware of the
Bad assumption. Non-decreasing time is a lot like arithmetic
overflow... programmers often don't consider the possibility. That's
reality. But how could a user be expected to be aware of the effects
of the non-decreasing presumption hidden in code which is executed on
Conrad Minshall h:408-446-2323 rad at acm.org / w:408-974-2749 conrad at apple.com
More information about the krbdev