...
This clause gives compilers the leeway to remove code deemed unused or unneeded when building a program. While this is usually beneficial, sometimes the compiler removes code that it thinks is not needed but which has been added with security in mind. An example of this is clearing out overwriting the memory of a buffer which that is used to store sensitive data. As a result, care must always be taken when dealing with sensitive data to ensure that operations on it always execute as intended.
Non-Compliant Code Example (memset())
Some compiler optimization modes may remove code sections if the optimizer determines that doing so will not alter the behavior of the program. In this non-compliant code example, optimization may remove the call to memset() (which the programmer had hoped would clear sensitive memory) to be removed because the variable is not accessed following the write. Check compiler documentation for information about this compiler-specific behavior and which optimization levels can cause this behavior to occur.
| Code Block | ||
|---|---|---|
| ||
void getPassword() {
char pwd[64];
if (GetPassword(pwd, sizeof(pwd))) {
/* checking of password, secure operations, etc */
}
memset(pwd, 0, sizeof(pwd));
}
|
Some compiler optimization modes may remove code sections if the optimizer determines that doing so will not alter the behavior of the program. In this example, this can cause the call to memset() (which the programmer had hoped would clear sensitive memory) to be removed because after the store to the variable, it is never accessed again. Check compiler documentation for information about this compiler-specific behavior and which optimization levels can cause this behavior to occur.
For all of the compliant solutions provided for this recommendation, it is strongly recommended that the programmer inspect the generated assembly code in the optimized release build to ensure that memory is actually cleared and none of the function calls are optimized out.
...
This non-compliant code example accesses the buffer again after the call to memset(). This prevents some compilers from optimizing out the call to memset() but does not work for all implementations. For example, the MIPSpro compiler and versions 3 and later of GCC cleverly nullify only the first byte and leave the rest intact. Check compiler documentation to guarantee this behavior for a specific platform.
| Code Block | ||
|---|---|---|
| ||
void getPassword() {
char pwd[64];
if (retrievePassword(pwd, sizeof(pwd))) {
/*checking of password, secure operations, etc */
}
memset(pwd, 0, sizeof(pwd));
*(volatile char*)pwd= *(volatile char*)pwd;
}
|
Implementation Details
...
Non-Compliant Code Example (Windows)
This compliant solution uses a the ZeroMemory() function provided by many versions of the Microsoft Visual Studio compiler.
...
This compliant solution uses a SecureZeroMemory() function provided by many versions of the Microsoft Visual Studio compiler. The documentation for the SecureZeroMemory() function guarantees that the compiler will does not optimize out this call when zeroing memory.
...
Compliant Solution (Windows)
The #pragma directives here in this compliant solution instructs the compiler to avoid optimizing the enclosed code. This #pragma directive is supported on some versions of Microsoft Visual Studio, and may be supported on other compilers. Check compiler documentation to ensure its availability and its optimization guarantees.
...
This compliant solution uses the volatile type qualifier to help flag to inform the compiler that the memory should be overwritten and that the call to the memset_s() function should not be optimized out. Unfortunately, this compliant solution may not be as efficient as possible due to the nature of the volatile type qualifier preventing the compiler from optimizing the code at all. Typically, some compilers are smart enough to replace calls to memset() with equivalent assembly instructions which are much more efficient than the memset() implementation. Implementing a memset_s() function as below may prevent the compiler from using the optimal assembly instructions and may result in less efficient code. Check compiler documentation and the assembly output from the compiler.
...