Timeline for If the heap is zero-initialized for security, then why is the stack merely uninitialized?
Current License: CC BY-SA 4.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 29, 2019 at 22:29 | comment | added | Peter Cordes | @thb and Toby: fun fact: new pages from the kernel are often lazily allocated, and merely copy-on-write mapped to a shared zeroed page. This happens for mmap(MAP_ANONYMOUS) unless you use MAP_POPULATE as well. New stack pages are hopefully backed by fresh physical pages and wired up (mapped in the hardware page tables, as well as the kernel's pointer/length list of mappings) when growing, because normally new stack memory is being written when touched for the first time. But yes, the kernel must avoid leaking data somehow, and zeroing is the cheapest and most useful. | |
| Mar 29, 2019 at 0:58 | comment | added | eckes | If you need initialized memory using calloc might be an option (instead of memset) | |
| Mar 29, 2019 at 0:35 | comment | added | Bob | Linux manpages note "4.3BSD; SUSv1, marked LEGACY in SUSv2, removed in POSIX.1-2001" but not deprecated in Linux and malloc on Linux still uses it in some situations. FreeBSD manpages say "The brk() and sbrk() functions are legacy interfaces from before the advent of modern virtual memory management. They are deprecated and not present on the arm64 or riscv architectures. The mmap(2) interface should be used to allocate pages instead." | |
| Mar 28, 2019 at 22:55 | comment | added | Joshua | On the other hand, malloc is deliberately a swappable component. Implementing malloc w/o any legacy functions pretty much implies mmap. | |
| Mar 28, 2019 at 22:03 | comment | added | Toby Speight | @Joshua, that page says "The use of malloc() is now preferred", i.e. a higher-level library function, rather than recommending alternative system calls. malloc() implementations aren't really subject to that recommendation, almost by definition. | |
| Mar 28, 2019 at 21:56 | comment | added | Joshua | @TobySpeight: brk and sbrk are obsoleted by mmap. pubs.opengroup.org/onlinepubs/7908799/xsh/brk.html says LEGACY right at the top. | |
| Mar 28, 2019 at 21:36 | history | edited | Toby Speight | CC BY-SA 4.0 | Try to be even clearer |
| Mar 28, 2019 at 21:34 | comment | added | Toby Speight | @Joshua, can you cite a standard that says that dynamic allocations need to be zero-filled? Anonymous mmap() is zero-initialised, but I can't find a corresponding guarantee for sbrk() - and malloc() may use either, or indeed a combination of both. | |
| Mar 28, 2019 at 21:31 | history | edited | Toby Speight | CC BY-SA 4.0 | Try to be even clearer |
| Mar 28, 2019 at 21:23 | comment | added | Toby Speight | @thb, Perhaps I'm not being clear enough - most implementations of malloc() do absolutely nothing with the memory they hand you - it's either previously-used, or freshly-assigned (and therefore zeroed by the OS). In your test, you evidently got the latter. Similarly, the stack memory is given to your process in the cleared state, but you don't examine it far enough to see parts your process hasn't yet touched. Your stack memory is cleared before it's given to your process. | |
| Mar 28, 2019 at 20:49 | comment | added | thb | If it interests you, I have added the second experiment to the question. | |
| Mar 28, 2019 at 20:39 | comment | added | Joshua | Uhh, if you call a low enough level call it is indeed guaranteed to be filled with zeros. | |
| Mar 28, 2019 at 20:16 | comment | added | thb | A week or two ago, I tried a different experiment, calling malloc() and free() repeatedly. Though nothing requires malloc() to reuse the same storage recently freed, in the experiment, malloc() did happen to do that. It happened to return the same address each time, but also nulled the memory each time, which I had not expected. This was interesting to me. Further experiments have led to today's question. | |
| Mar 28, 2019 at 20:11 | comment | added | thb | Your answer is good as far as it goes, +1, but my question has lent itself to misunderstanding. I have edited the question to clarify that I am not asking not about the requirements of the C standard (if I were asking that, I would ask on Stack Overflow) but about the observed behavior of GNU/Linux systems. | |
| Mar 28, 2019 at 19:53 | history | answered | Toby Speight | CC BY-SA 4.0 |