Hfrxdjt

On my Debian GNU/Linux 9 system, when a binary is executed,

• the stack is uninitialized but


• the heap is zero-initialized.

Why?

I assume that zero-initialization promotes security but, if for the heap, then why not also for the stack? Does the stack, too, not need security?

My question is not specific to Debian as far as I know.

Sample C code:

#include <stddef.h>
#include <stdlib.h>
#include <stdio.h>

const size_t n = 8;

// --------------------------------------------------------------------
// UNINTERESTING CODE
// --------------------------------------------------------------------
static void print_array(
 const int *const p, const size_t size, const char *const name
)

 printf("%s at %p: ", name, p);
 for (size_t i = 0; i < size; ++i) printf("%d ", p[i]);
 printf("n");


// --------------------------------------------------------------------
// INTERESTING CODE
// --------------------------------------------------------------------
int main()

 int a[n];
 int *const b = malloc(n*sizeof(int));
 print_array(a, n, "a");
 print_array(b, n, "b");
 free(b);
 return 0;

Output:

a at 0x7ffe118997e0: 194 0 294230047 32766 294230046 32766 -550453275 32713 
b at 0x561d4bbfe010: 0 0 0 0 0 0 0 0 

The C standard does not ask malloc() to clear memory before allocating it, of course, but my C program is merely for illustration. The question is not a question about C or about C's standard library. Rather, the question is a question about why the kernel and/or run-time loader are zeroing the heap but not the stack.

ANOTHER EXPERIMENT

My question regards observable GNU/Linux behavior rather than the requirements of standards documents. If unsure what I mean, then try this code, which invokes further undefined behavior (undefined, that is, as far as the C standard is concerned) to illustrate the point:

#include <stddef.h>
#include <stdlib.h>
#include <stdio.h>

const size_t n = 4;

int main()

 for (size_t i = n; i; --i) 
 int *const p = malloc(sizeof(int));
 printf("%p %d ", p, *p);
 ++*p;
 printf("%dn", *p);
 free(p);
 
 return 0;

Output from my machine:

0x555e86696010 0 1
0x555e86696010 0 1
0x555e86696010 0 1
0x555e86696010 0 1

As far as the C standard is concerned, behavior is undefined, so my question does not regard the C standard. A call to malloc() need not return the same address each time but, since this call to malloc() does indeed happen to return the same address each time, it is interesting to notice that the memory, which is on the heap, is zeroed each time.

The stack, by contrast, had not seemed to be zeroed.

I do not know what the latter code will do on your machine, since I do not know which layer of the GNU/Linux system is causing the observed behavior. You can but try it.

Regardless of how the stack is initialised, you’re not seeing a pristine stack, because the C library does a number of things before calling main, and they touch the stack.

With the GNU C library, on x86-64, execution starts at the _start entry point, which calls __libc_start_main to set things up, and the latter ends up calling main. But before calling main, it calls a number of other functions, which causes various pieces of data to be written to the stack. The stack’s contents aren’t cleared in between function calls, so when you get into main, your stack contains leftovers from the previous function calls.

This only explains the results you get from the stack, see the other answers regarding your general approach and assumptions.

The storage returned by malloc() is not zero-initialized. Do not ever assume it is.

In your test program, it's just a fluke: I guess the malloc()just got a fresh block off mmap(), but don't rely on that, either.

For an example, if I run your program on my machine this way:

$ echo 'void __attribute__((constructor)) p(void)
 void *b = malloc(4444); memset(b, 4, 4444); free(b);
' | cc -include stdlib.h -include string.h -xc - -shared -o pollute.so

$ LD_PRELOAD=./pollute.so ./your_program
a at 0x7ffd40d3aa60: 1256994848 21891 1256994464 21891 1087613792 32765 0 0
b at 0x55834c75d010: 67372036 67372036 67372036 67372036 67372036 67372036 67372036 67372036

In both cases, you get uninitialized memory, and you can't make any assumptions about its contents.

When the OS has to apportion a new page to your process, it guarantees that it won't expose data from other processes; the usual way to ensure that is to fill it with zeros (but it's equally valid to overwrite with anything else, including even a page worth of /dev/urandom - in fact some debugging malloc() implementations write non-zero patterns, to catch mistaken assumptions such as yours).

If malloc() can satisfy the request from memory already used in this process, its contents won't be cleared (in fact, the clearing is nothing to do with malloc() and it can't be - it has to happen before the memory is mapped into your address space). You may get memory that has previously been written by your process/program (e.g. before main()).