More on in-memory zeroisation

[Thierry Moreau]

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)
> function.

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 
wildests dreams.

> 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)()


Regards,

-- 

- Thierry Moreau

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