More on in-memory zeroisation

[Thierry Moreau]

Jack:

Thank you for pointing this. I must admit you point to an inescapable 
counter-example for my analysis.

Maybe global optimization was not a significant factor in the 1980's 
when the C standard language was established -- it does refer to 
external linkage and "genuine function".

In the case of volatile declaration, the GCC 4.2.2 compiler gave me a 
warning that the volatile qualifier was ignored because the memset 
formal parameter declaration does not match. At least, as a compiler 
user I get a proper warning message.

Regards

  - Thierry Moreau


Original message:

Jack Lloyd wrote:

> On Wed, Dec 12, 2007 at 05:27:38PM -0500, Thierry Moreau wrote:
> 
>>As a consequence of alleged consensus above, my understanding of the C 
>>standard would prevail and (memset)(?,0,?) would refer to an external 
>>linkage function, which would guarantee (to the sterngth of the above 
>>consensus) resetting an arbitrary memory area for secret intermediate 
>>result protection.
> 
> 
> GCC on x86-64 (-O2) compiles this function to the same machine code
> regardless of the value of ZEROIZE:
> 
> #include <string.h>
> 
> int sensitive(int key)
>    {
>    char buf[16];
>    int result = 0;
>    size_t j;
> 
>    for(j = 0; j != sizeof(buf); j++)
>       buf[j] = key + j;
> 
>    for(j = 0; j != sizeof(buf); j++)
>       result += buf[j];
> 
> #if ZEROIZE
>    (memset)(buf, 0, sizeof(buf));
> #endif
> 
>    return result;
>    }
> 
> Even if (memset) must refer to a function with external linkage (an
> analysis I find dubious), there is nothing stopping the compiler from
> doing IPA/whole program optimization - especially with a very basic
> function like memset (in the code above, if buf is declared volatile,
> GCC does do the memset: but it does it by moving immediate zero values
> directly to the memory locations, not by actually jumping to any
> external function).
> 
> Regards,
>   Jack

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com