Did you *really* zeroize that key?

Gil Hamilton gil_hamilton at hotmail.com
Fri Nov 8 10:50:28 PST 2002


Peter Gutmann writes:
>"James A. Donald" <jamesd at echeque.com> writes:
>
> >If the optimizer ever optimizes away a write to volatile
> >memory, device drivers will fail.  Most device drivers are
> >written in C.  If anyone ever produces a C compiler in which
> >"volatile" does not do what we want, not only are they out of
> >spec, but smoke will start coming out of hardware when the
> >device drivers are recompiled.
>
>The people who assume that any compiler which compiles their code gets
>an obscure feature like volatile exactly as per the spec are probably the
>same ones who assume that fixed-size buffers will never be exceeded.

I don't understand this extraordinary level of concern  As both James
and Perry have tried to point out, 'volatile' is *not* an obscure
feature.  Maybe it was obscure back in the mid-1980s, but every C
compiler I've seen in years supports volatile.  Its behavior has been
part of the C std for a long time now, and it's a critical part of a
large body of code on pretty much every platform.

It's interesting that you bring up the subject of "fixed size buffers"
being overrun.  That also results from ignorance and carelessness on
the programmer's part *not* from incorrect compiler implementation.

>It's my job to be paranoid.  I will assume that an arbitrary compiler
>gets a while() loop right (it'd be obvious if it didn't), but I won't
>gamble my crypto keys over assumptions about the correct handling of
>volatile in all compilers.

It sounds like the problem is more a lack of understanding of what
'volatile' means.  Nowhere in this thread (or from what I can tell,
the thread on vuln-dev) has anyone alleged that an actual compiler
didn't handle 'volatile' correctly.

- GH


_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail





More information about the cypherpunks-legacy mailing list