Anonymous mmap with zero padding?

Question

On Linux, the mmap (2) man page explains that anonymous mapping

. is not supported by any file; its contents are initialized to zero.

The personal page in FreeBSD mmap (2) does not give a similar guarantee of zero filling, although it does promise that bytes after the file is completed in an anonymous display are filled with zeros.

What Unix flavors promise to return zero memory initialization from anonymous mmaps? Which of them return zero initialized memory in practice, but do not make such a promise on their manual pages?

It seems to me that zero padding is partly due to security concerns. I wonder if any mmap implementations are allowed to skip zero padding for a page that was mmapped, munmapped, and then mmapped again by a single process, or if any implementations fill the newly displayed page with pseudo-random bits or some non-zero constant.

PS Apparently even brk and sbrk are used to provide zero pages. My Linux experiments seem to indicate that even if full pages are filled with zeros when a page error after calling sbrk highlights them, partial pages are not:

#include <unistd.h> #include <stdio.h> int main() { const intptr_t many = 100; char * start = sbrk(0); sbrk(many); for (intptr_t i = 0; i < many; ++i) { start[i] = 0xff; } printf("%d\n",(int)start[many/2]); sbrk(many/-2); sbrk(many/2); printf("%d\n",(int)start[many/2]); sbrk(-1 * many); sbrk(many/2); printf("%d\n",(int)start[0]); } 

Answer 1

It’s hard to say which ones promise that they simply do not exhaustively list all the pages of the manual or other release documentation, but the base code that processes MAP_ANON (usually? Always?) Is also used for matching in bss space for executable files and bss space must be filled with zeros. So this is pretty damn likely.

As for the "return of your old values" (or some non-zero values, but most likely your old ones), if you cancel and reconfigure, it certainly seems possible if some system should be "lazy" about freeing. I used only a few systems that support mmap in the first place (BSD and Linux derivatives), and none of them are lazy, at least not in processing the kernel code of mmap .

The cause of sbrk may or may not be the zero filling of the “reborn” page, probably due to the story or its absence. The current FreeBSD code corresponds to what I remember from the old pre- mmap days: there are two semi-secret variables, minbrk and curbrk , and both brk and sbrk will only call SYS_break (a real system call) if they move curbrk to a value that is at least minbrk . (Actually, it looks a little broken: brk has at least a behavior, but sbrk just adds its argument to curbrk and calls SYS_break . It seems harmless as the kernel checks in sys_obreak() in /sys/vm/vm_unix.c , so too negative sbrk() will end with EINVAL .)

I will need to look at the Linux C library (and then, possibly, the kernel code), but it can simply ignore attempts to “lower the gap” and simply write the value of the “logical gap” to libc. If you have mmap() and no backward compatibility requirements, you can implement brk() and sbrk() completely in libc using anonymous mappings, and it would be trivial to implement both of them as "just growing", as it were.