Baseline for Ed 2 of tr 24772

6.3 Bit Representations [STR]

6.3.1 Description of application vulnerability

Interfacing with hardware, other systems and protocols often requires access to one or more bits in a single computer word, or access to bit fields that may cross computer words for the machine in question. Mistakes can be made as to what bits are to be accessed because of the “endianness” of the processor (see below) or because of miscalculations. Access to those specific bits may affect surrounding bits in ways that compromise their integrity. This can result in the wrong information being read from hardware, incorrect data or commands being given, or information being mangled, which can result in arbitrary effects on components attached to the system.

6.3.2 Cross reference

JSF AV Rules 147, 154 and 155

MISRA C 2012: 1.1, 6.1, 6.2, and 10.1

MISRA C++ 2008: 5-0-21, 5-2-4 to 5-2-9, and 9-5-1

CERT C guidelines: EXP38-C, INT00-C, INT07-C, INT12-C, INT13-C, and INT14-C

Ada Quality and Style Guide: 7.6.1 through 7.6.9, and 7.3.1

6.3.3 Mechanism of failure

Computer languages frequently provide a variety of sizes for integer variables. Languages may support short, integer, long, and even big integers. Interfacing with protocols, device drivers, embedded systems, low level graphics or other external constructs may require each bit or set of bits to have a particular meaning. Those bit sets may or may not coincide with the sizes supported by a particular language implementation. When they do not, it is common practice to pack all of the bits into one word. Masking and shifting of the word using powers of two to pick out individual bits or using sums of powers of 2 to pick out subsets of bits (for example, using 28=2²+2³+2⁴ to create the mask 11100 and then shifting 2 bits) provides a way of extracting those bits. Knowledge of the underlying bit storage is usually not necessary to accomplish simple extractions such as these. Problems can arise when programmers mix their techniques to reference the bits or output the bits. Problems can arise when programmers mix arithmetic and logical operations to reference the bits or output the bits. The storage ordering of the bits may not be what the programmer expects.

Packing of bits in an integer is not inherently problematic. However, an understanding of the intricacies of bit level programming must be known. Some computers or other devices store the bits left-to-right while others store them right-to-left. The kind of storage can cause problems when interfacing with external devices that expect the bits in the opposite order. One problem arises when assumptions are made when interfacing with external constructs and the ordering of the bits or words are not the same as the receiving entity. Programmers may inadvertently use the sign bit in a bit field and then may not be aware that an arithmetic shift (sign extension) is being performed when right shifting causing the sign bit to be extended into other fields. Alternatively, a left shift can cause the sign bit to be one. Bit manipulations can also be problematic when the manipulations are done on binary encoded records that span multiple words. The storage and ordering of the bits must be considered when doing bit-wise operations across multiple words as bytes may be stored in big-endian or little-endian format.

6.3.4 Applicable language characteristics

This vulnerability description is intended to be applicable to languages with the following characteristics:

• 
  Languages that allow bit manipulations.
  

6.3.5 Avoiding the vulnerability or mitigating its effects

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

• 
  Explicitly document any reliance on bit ordering such as explicit bit patterns, shifts, or bit numbers.
  
• 
  Understand the way bit ordering is done on the host system and on the systems with which the bit manipulations will be interfaced.
  
• 
  Where the language supports it, use bit fields in preference to binary, octal, or hex representations.
  
• 
  Avoid bit operations on signed operands.
  
• 
  Localize and document the code associated with explicit manipulation of bits and bit fields.
  
• 
  Use static analysis tools that identify and report reliance upon bit ordering or bit representation.
  

6.3.6 Implications for standardization

In future standardization activities, the following items should be considered:

• 
  For languages that are commonly used for bit manipulations, an API (Application Programming Interface) for bit manipulations that is independent of word size and machine instruction set should be defined and standardized.
  

6.4 Floating-point Arithmetic [PLF]

6.4.1 Description of application vulnerability

Most real numbers cannot be represented exactly in a computer. To represent real numbers, most computers use IEC 60559 Information technology -- Microprocessor Systems -- Floating-Point arithmetic. If IEC 60559 is not followed, then the bit representation for a floating-point number can vary from compiler to compiler and on different platforms, however, relying on a particular representation can cause problems when a different compiler is used or the code is reused on another platform. Regardless of the representation, many real numbers can only be approximated since representing the real number using a binary representation may well require an endlessly repeating string of bits or more binary digits than are available for representation. Therefore it should be assumed that a floating-point number is only an approximation, even though it may be an extremely good one. Floating-point representation of a real number or a conversion to floating-point can cause surprising results and unexpected consequences to those unaccustomed to the idiosyncrasies of floating-point arithmetic.

Many algorithms that use floating point can have anomalous behaviour when used with certain values. The most common results are erroneous results or algorithms that never terminate for certain segments of the numeric domain, or for isolated values. Those without training or experience in numerical analysis may not be aware of which algorithms, or, for a particular algorithm, of which domain values should be the focus of attention.

In some hardware, precision for intermediate floating point calculations may be different than that suggested by the data type, causing different rounding results when moving to standard precision modes.

6.4.2 Cross reference

JSF AV Rules: 146, 147, 184, 197, and 202

MISRA C 2012: 1.1 and 14.1

MISRA C++ 2008: 0-4-3, 3-9-3, and 6-2-2

CERT C guidelines: FLP00-C, FP01-C, FLP02-C and FLP30-C

Ada Quality and Style Guide: 5.5.6 and 7.2.1 through 7.2.8

6.4.3 Mechanism of failure

Floating-point numbers are generally only an approximation of the actual value. Expressed in base 10 world, the value of 1/3 is 0.333333… The same type of situation occurs in the binary world, but the numbers that can be represented with a limited number of digits in base 10, such as 1/10=0.1 become endlessly repeating sequences in the binary world. So 1/10 represented as a binary number is:

0.0001100110011001100110011001100110011001100110011…

Which is 0*1/2 + 0*1/4 + 0*1/8 + 1*1/16 + 1*1/32 + 0*1/64… and no matter how many digits are used, the representation will still only be an approximation of 1/10. Therefore when adding 1/10 ten times, the final result may or may not be exactly 1.

Accumulating floating point values through the repeated addition of values, particularly relatively small values, can provide unexpected results. Using an accumulated value to terminate a loop can result in an unexpected number of iterations. Rounding and truncation can cause tests of floating-point numbers against other values to yield unexpected results. Another cause of floating point errors is reliance upon comparisons of floating point values or the comparison of a floating point value with zero. Tests of equality or inequality can vary due to rounding or truncation errors, which may propagate far from the operation of origin. Even comparisons of constants may fail when a different rounding mode was employed by the compiler and by the application. Differences in magnitudes of floating-point numbers can result in no change of a very large floating-point number when a relatively small number is added to or subtracted from it.

Manipulating bits in floating-point numbers is also very implementation dependent if the implementation is not IEC 60559 compliant or in the interpretation of NAN’s. Typically special representations are specified for positive and negative zero; infinity and subnormal numbers very close to zero. Relying on a particular bit representation is inherently problematic, especially when a new compiler is introduced or the code is reused on another platform. The uncertainties arising from floating-point can be divided into uncertainty about the actual bit representation of a given value (such as, big-endian or little-endian) and the uncertainty arising from the rounding of arithmetic operations (for example, the accumulation of errors when imprecise floating-point values are used as loop indices).

Note that most floating point implementations are binary. Decimal floating point numbers are available on some hardware and has been standardized in ISO/IEC/IEEE 60559:2011 (IEEE 754:2008), but be aware what precision guarantees your programming language makes. In general, fixed point arithmetic may be a better solution to common problems involving decimal fractions (such as financial calculations).

Implementations (libraries) for different precisions are often implemented in the highest precision. This can yield different results in algorithms such as exponentiation than if the programmer had performed the calculation directly.

Floating point systems have more than one rounding mode. Round to the nearest even number is the default for almost all implementations. Repeatedly rounding iterative calculations towards zero or away from zero can result in a loss of precision, and can cause unexpected outcome.

Floating point min and max can return an arbitrary sign when both parameters are zero (and of different sign). Tests that use the sign of a number rather than its relationship to zero can return unexpected results.

6.4.4 Applicable language characteristics

This vulnerability description is intended to be applicable to languages with the following characteristics:

• 
  All languages with floating-point variables can be subject to rounding or truncation errors.
  

6.4.5 Avoiding the vulnerability or mitigating its effects

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

• 
  Unless the program’s use of floating-point is trivial, obtain the assistance of an expert in numerical analysis and in the hardware properties of your system to check the stability and accuracy of the algorithm employed.
  
• 
  Do not use a floating-point expression in a Boolean test for equality unless it can be shown that the logic implemented by the equality test cannot be affected by prior rounding errors. Instead, use coding that determines the difference between the two values to determine whether the difference is acceptably small enough so that two values can be considered equal. Note that if the two values are very large, the “small enough” difference can be a very large number.
  
• 
  Verify that the underlying implementation is IEC 60559 (IEEE 754) or that it includes subnormal numbers (fixed point numbers that are close to zero). Be aware that implementations that do not have this capability can underflow to zero in unexpected situations.
  
• 
  Be aware that infinities, NAN and subnormal numbers may be possible and give special consideration to tests that check for those conditions before using them in floating point calculations.
  
• 
  Use library functions with known numerical characteristics. Avoid the use of a floating-point variable as a loop counter. If it is necessary to use a floating-point value for loop control, use inequality to determine the loop control (that is, <, <=, > or >=).
  
• 
  Understand the floating-point format used to represent the floating-point numbers. This will provide some understanding of the underlying idiosyncrasies of floating-point arithmetic.
  
• 
  Avoid manipulating the bit representation of a floating-point number. Prefer built-in language operators and functions that are designed to extract the mantissa, exponent or sign.
  
• 
  Do not use floating-point for exact values such as monetary amounts. Use floating-point only when necessary such as for fundamentally inexact values such as measurements or values of diverse magnitudes. Consider the use of fixed point arithmetic /libraries or decimal floating point when appropriate.
  
• 
  Use known precision modes to implement algorithms
  
• 
  Avoid changing the rounding mode from RNE (round nearest even)
  
• 
  Avoid reliance on the sign of the floating point Min and Max operations when both numbers are zero.
  
• 
  When adding (or subtracting) sequences of numbers, sort and add (or subtract) them from smallest to largest in absolute value to avoid loss of precision.
  

6.4.6 Implications for standardization

In future standardization activities, the following items should be considered:

• 
  Languages that do not already adhere to or only adhere to a subset of IEC 60559 [7] should consider adhering completely to the standard. Examples of standardization that should be considered:
  

• 
  Languages should consider providing a means to generate diagnostics for code that attempts to test equality of two floating point values.
  
• 
  Languages should consider standardizing their data type to ISO/IEC 10967-1:1994 and ISO/IEC 10967-2:2001.