At 10:20 AM 11/8/2002 +0000, Vincent Penquerc'h wrote:
On Thu, Nov 07, 2002 at 07:36:41PM -0500, Patrick Chkoreff wrote: > Everybody probably also knows about the gnupg trick, where they define a > recursive routine called "burn_stack": [...] > Then there's the vararg technique discussed in Michael Welschenbach's book > "Cryptography in C and C++":How about a simple alloca/memset ? Though it would possibly be more subject to `optimizations'. -- Vincent Penquerc'h
That's an interesting idea. You'd take the pointer returned by alloca and pass it to memset. How could the optimizer possibly know that the pointer pointed right into the stack frame? For all the compiler knew, the pointer might point to some device block somewhere, so the compiler would not dare remove the memset. UNLESS the compiler knew about alloca and by data flow analysis could establish that the pointer still pointed to the stack frame at the time of the memset. So yeah, it might indeed be subject to optimizations.
I was thinking the only way to really stymie the optimizer might be to have the program flow depend on something read from a file! You could have a file with a single 0 word in it. At the beginning of your program, just one time, you say this:
unsigned int fool_opt;
FILE *fp = fopen(....);
fread(&fool_opt,sizeof(unsigned int),1,fp);
The compiler has no idea there's a zero in fool_opt.
Now when you want to zero-out a variable, you'd say something like this:
unsigned int sensitive;
sensitive = result_of_bizarre_encryption();
/* Now let's zero out the sensitive variable. */
if (!fool_opt) sensitive = 0;
if (!sensitive) die_horribly_because_this_should_never_happen();
The "die horribly" routine would do something like this:
fprintf(stderr,"Yikes!\n");
exit(255);
I guarantee you, there is no way on earth an optimizer can get past that one!!
-- Patrick
http://fexl.com
