Jason Iannone wrote: > I can't cite chapter and verse but I seem to remember this zeroing > problem was solved decades ago by just introducing a bit which said > this chunk of memory or disk is new (to this process) and not zeroed > but if there's any attempt to actually access it then read it back as > if it were filled with zeros, or alternatively zero it.
That's true of virtual memory pages which are new to the process. But that isn't what malloc() usually returns, otherwise all malloc()ed allocations would require a 4KB virtual memory page. Rather malloc() and free() in the C library manage a pool of allocations and when that pool empties more virtual memory is allocated by using the brk() system call to ask the operating system for a new 4KB page of virtual memory -- which the operating system does set to zero, using the hardware to (perhaps lazily) set the page to zero if such a hardware feature is available. As a result the memory returned by malloc() often isn't zeroed and may contain data previously used by the process. Therefore a process can leak information between a program and its use of libraries. Because there is no inter-process information leakage this isn't seen as a problem in the traditional Unix view of security. You may have differing views if your program is a daemon servicing a multitude of networked users. Thus the interest in alternative malloc() and free() implementations. -- Glen Turner <http://www.gdt.id.au/~gdt/>
