RE: Software leaves encryption keys, passwords lying around in me mory

[Michael Wojcik <Michael.Wojcik () microfocus com>]

> From: pgut001 () cs auckland ac nz [mailto:pgut001 () cs auckland ac nz]
> Sent: Thursday, October 31, 2002 12:08 AM

> Dan Kaminsky <dan () doxpara com> writes:
>
> > Yes, but here you *hope* the compiler has the same semantics for
"volatile"
> > that you do. ... I'd rather *know*, at least at the same level of
> > confidence I have that I know anything else about the compiler.

Not in the general case; what we're hoping is that the compiler has the
semantics for "volatile" required by the language standard, as Pavel
Kankovsky has pointed out.  (The principle he cited for C99 is also in C90.
See ISO 9699-1990 6.5.3: "any expression referring to [a volatile] object
shall be evaluated strictly according to the rules of the abstract
machine".)

Note, though, that because the first parameter to memset is not
volatile-qualified, passing a volatile object to memset invokes undefined
behavior (see next paragraph).  A hand-coded loop should be substituted for
memset to properly implement the "volatile" solution.

> This is what makes it such a tough problem,

That remains to be demonstrated.  If you don't like the "volatile" solution
(I don't, because access to volatile objects may be significantly slowed,
and because aliasing volatile objects with non-volatile-qualified pointers
and accessing through such an alias invokes undefined behavior, and because
volatile seems like the sort of thing broken implementations may get wrong),
use the external-memset-wrapper one I proposed in my previous note.

> and why it may need compiler-level assistance.

The solutions are in the language.  All the compiler has to do is follow the
standard.

> You really can't rely on a kludge which just happens to work for one
version
> of the compiler

Properly using a feature required of all conforming implementations is not a
kluge.

Michael Wojcik
Principal Software Systems Developer, Micro Focus