It's extremely important to remember this in context: Heartbleed occurred on OpenBSD because OpenSSL had its own wrapper over malloc(). Instead of actually free()-ing those areas when calling openssl_free(), OpenSSL would leave them untouched and reuse them. If that had not been the case, and free() had in fact been called, reading past the actual payload boundaries would have yielded no useful results, because the malloc() in OpenBSD's libc would have cleared it (as opposed to openssl_malloc(), which was reusing previously un-free()-d zones).
In other words: idiomatic C and a sane malloc() implementation could have actually prevented Hearbleed.
It makes sense to assume that un-idiomatic Rust and reusing memory without clearing it would trigger the same bug.
By "sane malloc" do you mean one that gives you "cleared"/zeroed memory? I think it's a rarity and I think programs kinda assume that malloc takes, I dunno, 300-1000 cycles at worst when allocating many megabytes - whereas zeroing such buffers takes much more.
Or did I misunderstand your point about "malloc sanity"?
The section responsible for Hearbleed was never allocating more than 64 kilobytes, which can probably be cleared in 1000 cycles on most modern architectures.
As someone else pointed out, OpenBSD's malloc() implementation could have supplied a cleared memory area with no discernible performance impact (in fact, I think LibreSSL already does).
Technically yes (although, by default, no), but it's more efficient than that would imply. By default, I think only small chunks are overwritten, so OpenSSL's meagre 64 KB of Heartbleed payload would have been filled with useless junk, whereas multi-megabyte mallocs() in e.g. a RDBMS would have been unaffected.
There are some other protection mechanism included, too; there's a more in-depth presentation here:
If you follow the same faulty line of reasoning about performance and portability that led the OpenSSL team to introduce their incorrect wrapper over native malloc(), you will find that you'll reproduce Heartbleed using entirely safe code.
In other words: idiomatic C and a sane malloc() implementation could have actually prevented Hearbleed.
It makes sense to assume that un-idiomatic Rust and reusing memory without clearing it would trigger the same bug.