>
>
>volatile char key[ 16 ];
>
>(== don't optimise access to/from this var in any way)
>
>end of problem.
>
>
Yes, but here you *hope* the compiler has the same semantics for
"volatile" that you do. The "keys to the kingdom"(sufficient context to
zap your memset) are left in place; you just hope the compiler bothers
to ignore it. I'd rather *know*, at least at the same level of
confidence I have that I know anything else about the compiler.

Creating a dynamic dependancy during memory clearing effectively
deprives even the most rabidly optimizing compiler of, well, the keys to
leave your data untouched. You do have to accept that the compiler is
emitting assembly that is computationally equivalent to what you're
writing -- but this is a necessary batch of trust you need to give to
anything running your code, including the processor itself(which doesn't
even run assembly anymore, but a massively reordered form of microcode).
You also need to ignore that bizarre corner case where the same memory
address is mapped to multiple *physical* addresses -- such a memory
architecture could simply alter one of the addresses and tag the rest as
"tainted" without in fact clearing them. But I don't think anyone
actually does this -- I'm at least significantly more sure of that than
I am of the precise semantics of "volatile" vis-a-vis dead code elimination.

Yours Truly,

Dan Kaminsky
DoxPara Research
http://www.doxpara.com

[ reply ]