Re: how to avoid a memset() optimization

"Arthur Chance" <usenet-1ugeabe@qeng-ho.org>
13 Nov 2002 12:27:54 -0500

          From comp.compilers

Related articles
[5 earlier articles]
Re: how to avoid a memset() optimization lars@bearnip.com (Lars Duening) (2002-11-12)
Re: how to avoid a memset() optimization cgweav@aol.com (Clayton Weaver) (2002-11-12)
Re: how to avoid a memset() optimization n2102139816.ch@chch.demon.co.uk (Charles Bryant) (2002-11-13)
Re: how to avoid a memset() optimization dobes@dobesland.com (Dobes Vandermeer) (2002-11-13)
Re: how to avoid a memset() optimization fjh@cs.mu.OZ.AU (Fergus Henderson) (2002-11-13)
Re: how to avoid a memset() optimization jvorbrueggen@mediasec.de (Jan C. =?iso-8859-1?Q?Vorbr=FCggen?=) (2002-11-13)
Re: how to avoid a memset() optimization usenet-1ugeabe@qeng-ho.org (Arthur Chance) (2002-11-13)
Re: how to avoid a memset() optimization cfc@shell01.TheWorld.com (Chris F Clark) (2002-11-15)
Re: how to avoid a memset() optimization usenet-1ugeabe@qeng-ho.org (Arthur Chance) (2002-11-15)
Re: how to avoid a memset() optimization joachim_d@gmx.de (Joachim Durchholz) (2002-11-17)
Re: how to avoid a memset() optimization cfc@shell01.TheWorld.com (Chris F Clark) (2002-11-20)
Re: how to avoid a memset() optimization thp@cs.ucr.edu (2002-11-24)
Re: how to avoid a memset() optimization n1096001003.ch@chch.demon.co.uk (Charles Bryant) (2002-12-01)
| List of all articles for this month |

From: "Arthur Chance" <usenet-1ugeabe@qeng-ho.org>
Newsgroups: comp.compilers
Date: 13 Nov 2002 12:27:54 -0500
Organization: would be a fine thing to have
References: 02-11-030 02-11-040 02-11-049
Keywords: C, standards, comment
Posted-Date: 13 Nov 2002 12:27:54 EST

"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]


Post a followup to this message

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