> Any modern OS should zero allocated pages for security reasons alone. Just > to avoid leaking info across processes. Of course the OS could do this > zeroing when reclaiming pages, but I'd assume most would do it lazily and > just zero when they needed to re-allocate.
tl;dr If memory is allocated by mmap with MAP_ANONYMOUS, it will be zeroed this has pretty much always been the case. Heh. You don't even need to add the qualifier modern. This has basically just always been done. Most OSes now have a single "zero page" which is indeed a page full of zeroes. All new virtual memory (i.e. created with mmap w/ MAP_ANONYMOUS which incidentally grew out of mapping /dev/zero) is mapped to the zero page, but that page is marked read-only. When an application actually does a write, then, at that time, a fault occurs and a real zero page is allocated and provided. As to when pages are actually zeroed, when memory is returned to the OS, zeroing happens in a background thread and is only done on demand when there are no zeroed pages available. Now, all that said, this only applies to *new* virtual memory. If memory is allocated with malloc, it may have been recycled memory (from a previous free()) and there are no guarantees about whether or not the memory is zeroed. This particular patch seems to have to do with physical memory, and the for zeroed physical memory is system dependent. When a machine is booted, memory is of course random. In some systems the bios/console code zeroes memory before the OS starts and the OS may expect this behavior. On some systems, this does not happen since the OS knows it needs to zero the memory anyway. There were also projects like RIO (Peter Chen) that explicitly required physical memory to not be zeroed so the OS could be rebooted during a failure, but dirty cache data could be rescued. Kernels like linux probably take a least common denominator approach and assume nothing about zeroing, but embedded systems would potentially be different. Nate _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
