Re: thoughts on reallocarray, explicit_bzero?

[Rich Felker <dalias@libc.org>]

On Mon, May 19, 2014 at 06:45:08PM +0200, Daniel Cegiełka wrote:
> 2014-05-19 18:25 GMT+02:00 Szabolcs Nagy <nsz@port70.net>:
> 
> > i don't see how the openbsd explicit_bzero stops the
> > compiler to do optimizations..
> >
> > (i guess they rely on that their gcc does not do lto
> > or that libc is dynamic linked and the compiler has no
> > 'explicit_bzero' builtin, neither of which is a great
> > solution..)
> >
> > the usual approach to this is volatile function pointer:
> >
> > static void *(*volatile force_memset)(void,int,size_t) = memset;
> >
> > in general in c one cannot be sure that the secret bits
> > are not leaked somewhere since the languge spec cannot
> > give such guarantees
> >
> > that said either the volatile funcptr or actually reusing
> > the memory such that it cannot be optimized away works in
> > practice
> 
> first version:
> 
> void explicit_bzero(void * const b, const size_t l)
> {
>     volatile unsigned char *p = (volatile unsigned char *) b;
>     size_t i = (size_t) 0U;
> 
>     while (i < l) {
>         p[i++] = 0U;
>     }
> }
> 
> Of course, if someone has better ideas... I'm very curious :)

I'm pretty sure this does not work. The volatile pointer cast (which
BTW is not necessary; it happens implicitly) does not, as far as I can
tell, mean "access the object via an overlapped volatile object".
Rather, it just means that the compiler cannot _automatically_ assume
the pointed-to object is non-volatile. It's still free to determine
via other means (e.g. inter-procedural analysis/LTO/etc.) that the
pointed-to object is non-volatile (and of course, in cases where this
matters, that its lifetime is ending) and thereby optimize out the
whole thing as dead code.

Rich