Re: how to avoid a memset() optimization

"Lars Duening" <lars@bearnip.com> writes:
[On wiping sensitive data]


> I think the lesson to be learned here is that compiler writers would do
> well to give programmers some control over the compiler mechanics not
> covered by the language. In this case, a construct
>
> #pragma eliminate_dead_code=no
> memset(key, 0, sizeof key);
> #pragma eliminate_dead_code=restore
>
> would state the programmer's intentions far clearer than any 'volatile'
> construct, and also allow other optimizations still be performed on the
> key.
> [I don't see what the difference is between "volatile" and "don't
> eliminate dead code". Volatile exists precisely to tell the compiler
> that code that might appear to be dead isn't. -John]


I'm not a language lawyer, nor do I play one on TV, and am loathe to
disagree with our esteemed moderator, but looking at my copy of the
ANSI C spec I find section 5.1.2.3, third paragraph, second sentence:


"An actual implementation need not evaluate part of an expression if
it can deduce that its value is not used and that no needed side
effects are produced (including any caused by calling a function or
accessing a volatile object)."


If key isn't used after the memset (or a version of it with a volatile
void * argument), then the setting of key is not needed for future
program execution, so can be omitted whether or not key is declared
volatile. Expecting the compiler to understand that wiping the key is
"needed" for security in this case is an AI-complete problem.


It would seem to me the only way to force the memset would be to
access key afterwards, as in


                memset(key, 0, sizeof key);
                if (key[0]) impossibleError(); /* presuming suitable defns */


[I went back and looked at 5.1.2.3. From the context it's clear that
the sentence means that calls to functions that modify storage and
accesses to volatile storage are examples of side effects that require
that an expression containing them to be evaluated. Hence a
conformant compiler couldn't optimize away the memset() in the first
place. As others have noted, there's lots of other places the key
could be hanging around that no amount of buffer erasing would
handle. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.