Baseline for Ed 2 of tr 24772

7.32 Clock Issues [CCI]

7.32.1 Description of application vulnerability

All processors and operating systems maintain multiple representations of time internal to the system. In a typical system there are the following notions of time, and potentially identifiable clocks:

• 
  CPU time
  
• 
  Process/task/thread execution time
  
• 
  Calendar clock time, local and/or GMT
  
• 
  Elapsed time - i.e. time since system inception in seconds, or in fixed portions thereof
  
• 
  Network time
  

These times have different representations, different scaling, and different semantics. For example, a time-of-day clock must account for leap years, leap seconds and standard/daylight saving times. A CPU or processor clock is a monotonic clock that must maintain time used by a task, thread, or process in a granularity appropriate to CPU speed - possibly sub-nanosecond. A real time clock is a monotonic clock that manages and represents time to a granularity and representation needed to correctly manage the algorithms of the system. Both are usually associated with inputs from external devices or systems and outputs to initiate events in connected systems.

Some of these clocks are manifested in programming languages. For example, most languages have time of day clock lookup, while real time languages often include monotonic clocks for various purposes. Alternatively, some languages provide library services to access and manipulate time bases, and to schedule activity based upon one of the time bases.

Time Conversion

When multiple time bases are supported, there are mechanisms to convert from one time format to another to support calculations done. Conversion errors, rounding errors or cumulative errors can develop:

• 
  If the conversion is not done from the most precise time formats to less precise time formats,
  
• 
  If conversions are done from one format to another and then back for comparison, or
  
• 
  If iterative calculations are done using less than the most precise time base possible.
  

This can lead to missed deadlines or wrong calculations that depended on accurate time representation and can result in catastrophic loss of the application or the parent system. A classic example of this is the common (wrong) paradigm to use the calendar clock to derive values to be programmed into the monotonic clock.

Synchronicity

When code is written for an application, the developer usually assumes that there is a common time base for all portions of the application that are in communication with each other. When the system is spread over multiple processors, it the time base used by each processor will either drift from each other, or the time delay in communicating between these partitions will cause apparent drift.

Time Roll-over

Because each clock has a fixed internal representation of time which is updated periodically by some amount, eventually, if the system is long-enough lived, the time representation will completely fill the storage and will roll-over and return to zero, or the initial time. This can also happen if the time base is external, such as the global positioning satellite time base. Code that relies upon the time-base constantly increasing will fail if/when a rollover occurs, leading to failure of the computational system and possible catastrophic loss of the parent system, unless the application is programmed to account for this rollover.

Most systems create a real-time time base such that the system will never roll over within the expected operational time of the system. Modifications to the system, however, such as speeding up the clock that feeds the time base or dramatically increasing the expected operational lifetime of the system can make such errors happen, with potential catastrophic loss of the system and any systems that depend upon it.

7.32.2 Cross References

TBD

7.32.3 Mechanism of failure

The time of day clock is adjusted internally to jump or to be set backwards when going to or leaving summer time, inserting leap seconds, switching time zones or correcting time to synchronize the clock with a time base or another clock. Using the wrong clock, especially the time-of-day clock, to schedule events can result in jitter in the system, events being scheduled early, or the event being late. The mis-scheduling of events can have real world applications up to and including catastrophic loss of the parent system.

Converting from one time-base to another time-base can result in loss of precision, rounding errors, and conversion errors which can lead to complete jitter in the application behavior or complete failure of the application

Roll-over of a clock can cause failure of applications that are expecting uniformly increasing time, which can lead to transient failure of the application and possibly the parent system.

7.32.4 Avoiding the vulnerability or mitigating its effect

Software developers can avoid the vulnerability or mitigate its effects in the following ways:

• 
  Always convert time from the most precise and stable time base to less precise time bases.
  
• 
  Avoid conversions from calendar clocks or network clocks to real time clocks.
  
• 
  Avoid using the time of day clock to schedule events, unless the event is demonstrably connect with real world time of day, such as setting an alarm for 7 am.
  
• 
  Avoid resetting or reprogramming the real-time clock or execution timers, unless the complete application is being reset. Allow some variability or error margin in the reading of time and the scheduling of time based on the read.
  
• 
  Use only clocks that have known synchronization properties.
  
• 
  Protect any code that uses real-time time bases with any potential of roll-over from going from a large value to a zero or a negative value. This is done by assuming that a rollover can occur and if it is expected that always T1