More on in-memory zeroisation

[Leichter, Jerry]

| I've been through the code.  As far as I can see, there's nothing in
| expand_builtin_memset_args that treats any value differently, so there
| can't be anything special about memset(x, 0, y).  Also as far as I can
| tell, gcc doesn't optimise out calls to memset, not even thoroughly
| dead ones....
While good for existing crypto code, this is exactly the kind of thing
that's a problem.  We now have a well-distributed bit of folk knowledge
that memset(x,0,y) is treated specially by the compiler.  It isn't; this
"knowledge" is just repeated inaccurate rumor.  Fortunately, "not
treated specially" in this case defaults to a case that does what we
want - but it also means that if someone makes the "code has no effect"
analyzer smarter in some release of gcc, all of a sudden, these memset()
calls that we're relying on may suddenly just disappear from the
generated code.  How long before anyone notices?  It's not as if the
change log will show "optimize away dead calls to memset" - it will
likely contain some obscure comment like "improve recognition that type
B subtrees can be collapsed in phase 3".

The only *safe* way to write code like this - absent explicit support
in the standard - is with explicit support in each particular compiler.
Even something like:

#pragma always_call memset

ugly as it is, would work.

							-- Jerry

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