On Fri, Nov 08, 2002 at 05:23:34PM +0100, Michael Zimmermann wrote: > Not to declare the intermediate storage for sensitive > data as 'volatile' is a coding flaw. An esily overlooked > one, yes, but nevertheless... Like forgetting to protect > critical code with semaphores.
'volatile' isn't sufficient to be safe. In fact, there's no way to be sure that some C code doesn't leave copies of sensitive data around, because there's nothing in the C standard that forbids the compiler to keep copies of data. 'volatile' only forbids certain usages of that data (provided that the implementation defined aspects of 'volatile' are defined in a sane way). Typical examples of such copies are temporary data while evaluating expressions, and copies of processor registers on the stack that are often required by the ABI. For example, take gcc-3.0.4 on Linux/ix86, optimizations turned off, and the following code: | #include <stddef.h> | extern void zero (volatile void *, size_t); | void foo3 (volatile unsigned long *keyl, | volatile unsigned long *keyr) | { | volatile unsigned long keyx; | keyx = (*keyl + *keyr) * (*keyl - *keyr) | - (*keyl ^ *keyr) * (~*keyl * ~*keyr); | bar3 (&keyx); | zero (&keyx, sizeof keyx); | } It's compiled to this assembly code (only a small snippet before the call to bar3()): | movl %ebx, %eax | movl %eax, -8(%ebp) | subl $12, %esp | leal -8(%ebp), %eax | pushl %eax | call bar3 The value of keyx is in register %ebx. If bar3() uses %ebx internally (which it probably does if it is non-trivial), the first thing after setting up the stack frame will be saving the old value of %ebx (i.e. keyx) on the stack. -- Jan fortune: can't load library '/libc.so.4' No such library.