3 ms·
Openssl uses their own memory allocator (since malloc is slow on big-endian x86 xenix or something) so they _do_ reuse memory without clearing it in between. H
by ksherlock 12y ago
Openssl uses their own memory allocator (since malloc is slow on big-endian x86 xenix or something) so they _do_ reuse memory without clearing it in between. Had they used the system malloc, it wouldn't have been vulnerable (on OpenBSD and probably elsewhere). Can rust prevent you from implementing your own (buggy) memory allocator?
- steveklabnik 12y agoYes, because we don't support custom allocators yet ;)
- Jweb_Guru 12y agoNo (well, there is still work to be done on custom allocators, but it's planned). But given that Rust uses jemalloc by default, not the system allocator, it is substantially less likely that you will want to replace it with your own. You certainly can't do it without copious amounts of unsafe code (which is really rather unfortunate).
- eddyb 12y agoYou would have to use unsafe code and isolate that as much as you can, behind a safe interface. Memory reuse without clearing would be considered safe, though, as none of the other abstractions actually let you read that memory (doing so would easily be UB anyways in LLVM).
- IshKebab 12y agoStandard `malloc` doesn't zero memory either. The problem was not caused by their custom allocator. It was exacerbated by it because it allocated everything really close together.
- masklinn 12y agoWell it's not really that it allocated everything really close together in memory-space, but since it would try to reuse existing memory from the freelist before asking the OS for more memory, you were more or less certain to get memory openssl had previously used as scratch space to, say, store a private key for temporary operations.