Zeroing core. 2580

It doesn't matter how you represent it. Binary, octal, hex, base 12, decimal whatever. I'm not buttuming a human will examine this, though I have (as in "core dump") done so. I'm buttuming that machine will work with it. My argument here as been that there's no inherent advantage to zero over some other value for the purpose of securely scrubbing core.

So long as the memory has BEEN scrubbed before giving it to the user mode code, it's secure.

Further, I'm saying that using something other than zero can have advantages which zero does not. As an example, if I'm working with C a call to calloc will clear the memory... to zeros, before the application gets to mess with it. If I'm debugging a foul up and find a pointer referencing a block of memory with the OS initialization pattern (perhaps 55AA(hex), 052652(octal) or even 0101010110101010(binary)) I'll know that someone forgot to initialize memory.

But, since the memory WAS scrubbed, there's no way the tables generated by Bob's earlier run of his encryption program will accidentally now be available to Jane's solitaire program.

If it IS a human examining the (say) core dump, a variation in the pattern will stand out about as well or, with the right choice, even better than 0000. If you're considering human examination, 1111 actually works better because it's the only number with that shape. Everything else is wider on the display.

0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0080 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

55AA 55AA 55AA 55AA 55AA 55AA 55AA 55AA 55AA 55AA 55AA 55AA 558A 55AA 55AA 55AA 55AA 55AA 55AA 55AA 55AA 55AA 55AA 55AA

1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1181 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111

- Bill