More on in-memory zeroisation
thierry.moreau at connotech.com
Tue Dec 11 15:56:20 EST 2007
Leichter, Jerry wrote:
> | > There was a discussion on this list a year or two back about
> | > problems in using memset() to zeroise in-memory data, specifically
> | > the fact that optimising compilers would remove a memset() on
> | > (apparently) dead data in the belief that it wasn't serving any
> | > purpose.
> | Then, s/memset(?,0,?)/(memset)(?,0,?)/ to get rid of compiler
> | in-lining.
> | Ref: ANSI X3.159-1989, section 4.1.6 (Use of C standard library
> | functions)
> I don't have te C89 spec handy (just the C99 spec, which is laid
> out differently), but from what I recall, this construct guarantees
> nothing of the sort.
> Most standard library functions can be implemented as macros. Using the
> construct (f)(args) guarantees that you get the actual function f,
> rather than the macro f.
Indeed, the actual function, memcpy in the present instance.
memcpy, the actual function, is aware of the execution environment,
because it is part of the run-time library. The compiler is not as
deeply aware of the execution environment.
The source code construct (f)(args) is provided by the standard to allow
the program to explicitly rely on the actual library function.
At least this is my understanding of compiler optimization techniques as
subordinate to standard definition of the C language. I too often turned
off optimization due to (suspected) optimized-in crash, I would like to
rely on the (f)(args) to locally turn off optimization.
> However, that doesn't say anything about
> whether f is actually invoked at run time. That comes under the "acts
> as if" rule: If the compiler can prove that the state of the C
> (notional) virtual machine is the same whether f is actually invoked or
> not, it can elide the call. Nothing says that memset() can't actually
> be defined in the appropriate header, as a static (or, in C99, inline)
The standard actually says "... it is permitted to take the address of a
library function even if it is defined as a macro ...". The standard
works for me as a source code author who needs an execution-aware memcpy
function from time to time. Overworked GCC contributors should work to
comply to the standard, not to address Peter, Thierry, and whoever's
> Then the compiler can look at the implementation and "prove"
> that a memset() to a dead variable can be elided....
It can't prove much in the case of (memset)()
- Thierry Moreau
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
More information about the cryptography