Re: DRAM data persistence

Jan Panteltje wrote:

On a sunny day (Thu, 05 Jul 2007 18:29:27 GMT) it happened
nico@xxxxxxxxxxx (Nico Coesel) wrote in
<468d36e1.1108693667@xxxxxxxxxxxxxx>:


I have just run the following program:
#include <stdlib.h>
#include <stdio.h>

int main(int argc, char **argv)
{
int a, i;
char *ptr;
char t[1000];

ptr = t;
for(i = 0; i < 1000; i++)
{
a = *ptr & 0xff;
fprintf(stdout, "%02x", a);

ptr++;
}

ptr = t;
for(i = 0; i < 1000; i++)
{
a = *ptr & 0xff;
fprintf(stdout, "%c", a);

ptr++;
}

exit(1);
} /* end function main */

Compiled like this:
gcc -o test test.c

Gives as result:
grml: ~ # ./test

2c57f2b77cadf3b78f50000010b0f3b7c088e3b7000000008255f2b7ac8204081037f2b7cc51f2b700000000fc53f2b7000000008caff3b705
etc etc...

So, pure DRAM, stack space...
And this is one of the latest Linux kernels:
grml: ~ # uname -a
Linux grml 2.6.21 #1 Sat May 5 17:08:45 CEST 2007 i686 GNU/Linux

gcc version 4.0.3 20060104

If you do the same with malloc() you get zeros only (as explained by an
otehr poster). Try it :-)

Hi Jan,

what you see are left over stack frames from the
C-library initialisation. If you extend the stack
into virgin territory you get the same zeros.
Try this:

#include <stdio.h>

void fun(int stage)
{
unsigned char b[1024];
if (stage>0)
fun(stage-1);
else
{
int i;
for (i=0; i<1024; i++)
{
printf("%02X",b[i]);
}
}
}

int main(void)
{
fun(1024);
return 0;
}

It grows the stack by slightly over 1MB and and
forces the mapping of new pages.

$ a.out
000000000000000000000000000000000000000000000000...

However, in both cases (malloc and automatic variables),
the space gets re-used by the runtime system. That is,
only the first ever malloc of a task contains zeros. If
you free that memory again, chances are that it gets
reused und you'll find you old content again in later
mallocs.

Linux protects tasks from each other and the kernel
from all of them. It is not considered a security
problem if a task leaks data to itself.

Kind regards,

Iwo

.

Relevant Pages

  • Re: is there anything unstandard in the c part here
    ... pa = (char*) malloc; ... Now the advice given was "if you change the type of *pa, the cast is ... int *pa; ... If you have a policy of casting the value returned by malloc(), ...
    (comp.lang.c)
  • Re: Segmentation fault on 64 bit
    ... using a HP-UX C compiler on PA-RISC system. ... malloc() and friends are defined. ... int main(int argc, char **argv) ... Obviously a pointer can't be stored in an int on the system ...
    (comp.lang.c)
  • Re: malloc modifying a passed string
    ... > without the necessary testing of malloc, ... > char *ptr; ... > to a previous post, the FAQ, or whatever is most applicable. ...
    (comp.lang.c)
  • Re: about the array
    ... return int and take an unknown number and type of arguments. ... void *ptr; ... if the declaration of malloc() isn't visible, ... attempting to assign an int to a void*. ...
    (comp.lang.c)
  • Re: free problem
    ... int *reserv_mem; ... ptr now contains the value returned by the malloc call in reserv_mem. ... And since the value is not acceptable free did you a favor by ...
    (comp.lang.c)