Back to list
RE: Software leaves encryption keys, passwords lying around in memory
Oct 31 2002 05:47PM
Michael Wojcik (Michael Wojcik microfocus com)
> From: pgut001 (at) cs.auckland.ac (dot) nz [email concealed] [mailto:pgut001 (at) cs.auckland.ac (dot) nz [email concealed]]
> Sent: Thursday, October 31, 2002 12:08 AM
> Dan Kaminsky <dan (at) doxpara (dot) com [email concealed]> writes:
> >Yes, but here you *hope* the compiler has the same semantics for
> >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
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
> You really can't rely on a kludge which just happens to work for one
> of the compiler
Properly using a feature required of all conforming implementations is not a
Principal Software Systems Developer, Micro Focus
[ reply ]
Copyright 2010, SecurityFocus