Comment by infinity0
8 years ago
Neither of these are good reasons: I already talked about MALLOC_PERTURB_ (man mallopt) in my post and my naive performance tests, and we rarely get bad security holes based on data from deleted files left on filesystems.
Unfortunately, people write microbenchmarks of malloc and free a lot (and not completely without reason: they do quite often show up high in profiles).
For example, binary-trees on the Benchmarks Game is basically malloc/free bound (or at least is supposed to be as Hans Boehm originally designed it). Likewise, most JavaScript benchmarks (V8 splay, for example) are heavily influenced by raw allocation performance. Many people choose browsers and programming languages based on relatively small differences in these results. All of the incentives align in favor of performance, not security, because performance is easy to measure and security is not.
You asked for a reason, not for a good reason.
malloc/free were designed around 1972. That was a time where performance was much more important and security concerns didn't really exists.
Modern systems, like Go, do zero-out newly allocated memory because they do consider a bit more security to be more important than a bit more performance.
But changing the defaults of malloc/free is not really an option and it would probably break stuff.
Especially on Linux, where, I believe, malloc returns uncommitted pages, which increases the perf advantage in some cases.
Security conscious programmers can use calloc() or write their own wrappers over malloc/free.
they aren't good reasons now. They were good reasons ~20 years ago.
language spec should probably now default to zeroing memory unless you specifically ask it not to....and maybe that should be a verbose option :)