Using Uninitialized Memory for Fun and Profit
research.swtch.com
research.swtch.com
Of course, it does work on pretty much every real computer.
But, of course, that misses the point of the article. ;-)
To say nothing about forcing a redesign of many memory products.
People writing fast, single-threaded network stuff may see immediate value w/r to poll(), or any other situation where you need a packed, easily update-able list of things.
malloc() allocates size bytes and returns a pointer to the allocated
memory. The memory is not cleared.
So I wrote a quickie:
#include <stdlib.h>
#include <stdio.h>
int main() {
int m = 1024*1024; //1M
int t = 1024*m; //total count: here 1G
char *v = calloc(1, t*sizeof(char)); //total size: 1GB
for(int i=0; i<t; i++)
{
if (v[i] != 0)
{
printf("%016u @%x %x\n", i, v+i, v[i]);
}
else if (i % (t/10) == 0)
{
printf("%016u @%x\n", i ,v+i);
}
}
}
I notice though that on Mac OS X the program starts right on the spot, while there is always a constant delay on Lucid. Looks like one zeroes on demand (by chunks probably) whereas the other zeroes initially.
From the Mac OS X man page:
The calloc() function contiguously allocates enough space for count objects that are size bytes of memory each and returns a pointer to the allocated memory. The allocated memory is filled with bytes of value zero.
Nice for security, but how would one proceed when really wanting pedal-to-the-metal performance?
When malloc returns memory previously freed by the process, it effectively returns uninitialized memory, without leaking any information that's not already known to the calling process.