7.33 Time Drift and Jitter [CDJ]
Many real time systems are characterized by collections of jobs waiting for a start-time for a time-based iteration, or an event for sporadic activities. A common mistake in programming such systems is to base the start time of the next iteration upon either a non-monotonic or a non-real time clock, or to base it upon an offset from the start time or completion time of the last iteration. In the first case, conversion errors and possible drift of the real time clock can cause the next iteration to be wrongly programmed. In the second case, higher priority work may have delayed the actual start or completion of the task in an individual iteration, resulting again in time drift.
With enough drift, an iterative task will begin missing its deadlines, and will either produce the wrong results, or will fail completely, resulting in arbitrary failures up to catastrophic loss of the enclosing system.
Many systems have moved to a virtualization approach to fielding systems. Sometimes the virtual system is only an OS change, such as running Windows and Linux on the same hardware. Sometimes the virtual system is hardware and software. Sometimes hardware is dedicated, such as 2 cores from an 8 core system, while in others the virtual system under consideration only executes when needed. The discussion of virtualization includes the common notions, such as hypervisors, but also include systems as diverse as satisfying ARINC 653[ARINC 653], which uses a time-based partition approach to schedule mixed criticality systems on a single CPU.
In any case, when a system is virtual, its connection with the real world (i.e. hardware and virtualizer) clocks is indirect. Clocks for the virtualized system are updated when the virtualized system resumes, and time may “jump” or may advance much faster than normal until the clocks are synchronized with the real world. Similarly, time may run slow in an executing virtualized system. Thesei behaviourss can result in processes being mis-synchronized or missing deadlines if time jumps or progresses too quickly for the task to get its work completed.
If an attacker is aware that an application is virtualized, or that it is depending upon a non-realtime clock, and can determine what other applications share the same resource, they may be able to generate load for the other virtualized applications so that the one in question can not retain enough resources to function correctly.
7.33.2 Cross references
TBD
7.33.3 Mechanism of failure
Any change in the progression of time can result in a disconnect between the spacing of the delivery of time events to the application, and can make jobs within the application run past their deadlines (as viewed by the timing events).
Deadline overrun is a serious flaw in the application, and usually results in failure of portions of the application up to catastrophic failure of the application, and may result in loss of the parent system.
When a system is virtualized, an attacker can use influence over other applications to consume resources needed by the critical system that could trigger such systems.
Programming mistakes, such as failure to use monotonic clocks to schedule iterations, or incorrectly programming the next iteration calculations (such as setting the next wake time based on the the start of the current wake time vs a fixed offset from the previous scheduled start time) result in drift or jitter which may result in missed real world inputs or loss of synchronization with external systems.
7.33.4 Avoiding the vulnerability or mitigating its effect
Software developers can avoid the vulnerability or mitigate its effects in the following ways:
-
Always set the next (absolute) start time for the iteration from the the start time of the previous programmed iteration.
-
Only use the real-time clock in scheduling tasks or events.
-
Create management jobs that can monitor and detect
-
Ensure that the behaviour of a virtualized application cannot be compromised by changes to the environment of the virtualized system.
.
8 New Vulnerabilities
Annex A
(informative)
Vulnerability Taxonomy and List A.1 General
This Technical Report is a catalog that will continue to evolve. For that reason, a scheme that is distinct from sub-clause numbering has been adopted to identify the vulnerability descriptions. Each description has been assigned an arbitrarily generated, unique three-letter code. These codes should be used in preference to sub-clause numbers when referencing descriptions because they will not change as additional descriptions are added to future editions of this Technical Report. However, it is recognized that readers may need assistance in locating descriptions of interest.
This annex provides a taxonomical hierarchy of vulnerabilities, which users may find to be helpful in locating descriptions of interest. A.2 is a taxonomy of the programming language vulnerabilities described in Clause 6 and A.3 is a taxonomy of the application vulnerabilities described in Clause 7. A.4 lists the vulnerabilities in the alphabetical order of their three-letter codes and provides a cross-reference to the relevant sub-clause.
A.2 Outline of Programming Language Vulnerabilities
A.2.1. Types
A.2.1.1. Representation
A.2.1.1.1. [IHN] Type System
A.2.1.1.2. [STR] Bit Representations
A.2.1.2. Floating-point
A.2.1.2.1. [PLF] Floating-point Arithmetic
A.2.1.3. Enumerated Types
A.2.1.3.1. [CCB] Enumerator Issues
A.2.1.4. Integers
A.2.1.4.1. [FLC] Numeric Conversion Errors
A.2.1.5. Characters and strings
A.2.1.5.1 [CJM] String Termination
A.2.1.5.2. [SHL] Reliance on External Format String
A.2.1.6. Arrays
A.2.1.6.1. [HCB] Buffer Boundary Violation (Buffer Overflow)
A.2.1.6.2. [XYZ] Unchecked Array Indexing
A.2.1.6.3. [XYW] Unchecked Array Copying
A.2.1.7. Pointers
A.2.1.7.1. [HFC] Pointer Casting and Pointer Type Changes
A.2.1.7.2. [RVG] Pointer Arithmetic
A.2.1.7.3. [XYH] Null Pointer Dereference
A.2.1.7.4. [XYK] Dangling Reference to Heap
A.2.2. Type-Conversions/Limits
A.2.2.1. [FIF] Arithmetic Wrap-around Error
A.2.2.1 [PIK] Using Shift Operations for Multiplication and Division
A.2.3. Declarations and Definitions
A.2.3.1. [NAI] Choice of Clear Names
A.2.3.2. [WXQ] Dead store
A.2.3.3. [YZS] Unused Variable
A.2.3.4. [YOW] Identifier Name Reuse
A.2.3.5. [BJL] Namespace Issues
A.2.3.6. [LAV] Initialization of Variables
A.2.4. Operators/Expressions
A.2.4.1. [JCW] Operator Precedence/Order of Evaluation
A.2.4.2. [SAM] Side-effects and Order of Evaluation
A.2.4.3. [KOA] Likely Incorrect Expression
A.2.4.4. [XYQ] Dead and Deactivated Code
A.2.5. Control Flow
A.2.5.1. Conditional Statements
A.2.5.1.1. [CLL] Switch Statements and Static Analysis
A.2.5.1.2. [EOJ] Demarcation of Control Flow
A.2.5.2. Loops
A.2.5.2.1. [TEX] Loop Control Variables
A.2.5.2.2. [XZH] Off-by-one Error
A.2.5.3. Subroutines (Functions, Procedures, Subprograms)
A.2.5.3.1. [EWD] Structured Programming
A.2.5.3.2. [CSJ] Passing Parameters and Return Values
A.2.5.3.3. [DCM] Dangling References to Stack Frames
A.2.5.3.4. [OTR] Subprogram Signature Mismatch
A.2.5.3.5. [GDL] Recursion
A.2.5.3.6. [OYB] Ignored Error Status and Unhandled Exceptions
A.2.5.4. Termination Fault ToleranceStrategy
A.2.5.4.1. [REU] Fault Tolerance and FailureTermination Strategiesy
A.2.6. Memory Models
A.2.6.1. [AMV] Type-breaking Reinterpretation of Data
A.2.6.2. Deep vs Shallow Copying [YAN]
A.2.6.3.2. [XYL] Memory Leak and Heap Fragmentation
A.2.7. Templates/GenericsContract Model
A.2.7.1. [SYM] Templates and Generics
A.2.7.2. [RIP] Inheritance
A.2.7.32. [BLP] Violations of the Liskov Substitution Principle or the Contract Model
A.2.7.4 [PPH] Redispatching
A.2.7.5 [BKK] Polymorphic Variables??????????????????????????
A.2.8. Libraries
A.2.8.1 [LRM] Extra Intrinsics
A.2.8.2. [TRJ] Argument Passing to Library Functions
A.2.8.3. [DJS] Inter-language Calling
A.2.8.4. [NYY] Dynamically-linked Code and Self-modifying Code
A.2.8.5. [NSQ] Library Signature
A.2.8.6. [HJW] Unanticipated Exceptions from Library Routines
A.2.9. Macros
A.2.9.1. [NMP] Pre-processor Directives
A.2.10. Compile/Run Time
A.2.10.1 [MXB] Suppression of Language-Defined Run-Time CheckingProvision of Inherently Unsafe Operations
A.2.10.2 [SKL] Suppression of Language-Defined Run-Time Checking Provision of Inherently Unsafe Operations
A.2.11. Language Specification Issues
A.2.11.1. [BRS] Obscure Language Features
A.2.11.2. [BQF] Unspecified Behaviour
A.2.11.3. [EWF] Undefined Behaviour
A.2.11.4. [FAB] Implementation-defined Behaviour
A.2.11.5. [MEM] Deprecated Language Features
A.2.12. Concurrency
A.2.12.1 [CGA] Concurrency – Activation
A.2.12.2 [CGT] Concurrency – Directed termination
A.2.12.3 [CGS] Concurrency – Premature Termination
A.2.12.4 [CGX] Concurrent Data Access
A.2.12.6 [CGM] Protocal Lock Errors
Dostları ilə paylaş: | 
