No subject

programs, this affects quite a bit of software.

The problem he points out is that clearing sensitive information such as
encryption keys from memory may not work as expected because an optimising
compiler removes the memset() if it decides it's redundant.  Consider for
example the following:

int encrypt( const void *key )
  {
  puts( key );     /* Normally we'd encrypt here */
  }

void main( void )  /* Because we can */
  {
  char key[ 16 ];
	
  strcpy( key, "secretkey" );
  encrypt( key );
  memset( key, 0, 16 );
  }

When compiled with any level of optimisation using gcc, the key clearing
call goes away because of dead code elimination (see the MSDN article for
more details on this, which uses VC++ to get the same effect).  While you
can kludge enough stuff around a custom memory-clear call to fool the
optimiser (hacks with 'volatile', touching the memory after it's cleared and
hoping the optimiser is fooled, etc) there's no guarantee that it'll
work for anything but the compiler(s) you happen to test it with - any
future enhancement to the optimiser may turn it back into a nop.  What it
really needs is the addition of a #pragma dont_remove_this_code_you_bastard
in the compiler.  Until then, a lot of security code will be affected by
this problem.

----

Ari Vennonen