3 ms·

True of the more common ones, but it should be acknowledged that OpenBSD was doing this kind of thing (and many other hardening techniques) before heartbleed, w

True of the more common ones, but it should be acknowledged that OpenBSD was doing this kind of thing (and many other hardening techniques) before heartbleed, which was the main reason Theo de Raadt was so upset that they decided to circumvent this, because OpenBSD's allocator could have mitigated the impact otherwise.

loeg 6y ago
Even higher-performance mallocs like jemalloc had heap debugging features (poisoning freed memory) before Heartbleed, which -- if enabled -- would catch use-after-frees, so long as libraries and applications didn't circumvent malloc like OpenSSL did (and Python still does AFAIK).
- supergarfield 6y ago
  > and Python still does AFAIK Don't you sort of have to do that if you're writing your own garbage collector, though? I guess for a simple collector you could maintain lists of allocated objects separately, but precisely controlling where the memory is allocated is important for any kind of performant implementation.
  - loeg 6y ago
    Python does refcount-based memory management. It's not a GC design. You don't have to retain objects in an internal linked list when the refcount drops to zero, but CPython does, purely as a performance optimization. Type-specific free lists (just a few examples; there are more): * https://github.com/python/cpython/blob/master/Objects/floatobject.c#L231-L245 https://github.com/python/cpython/blob/master/Objects/floato... * https://github.com/python/cpython/blob/master/Objects/tupleobject.c#L268-L290 https://github.com/python/cpython/blob/master/Objects/tupleo... And also just wrapping malloc in general. There's no refcounting reason for this, they just assume system malloc is slow (which might be true, for glibc) and wrap it in the default build configuration: https://github.com/python/cpython/blob/master/Objects/obmalloc.c#L733-L771 https://github.com/python/cpython/blob/master/Objects/obmall... So many layers of wrapping malloc, just because system allocators were slow in 2000. Defeats free() poisoning and ASAN. obmalloc can be disabled by turning off PYMALLOC, but that doesn't disable the per-type freelists IIRC. And PYMALLOC is enabled by default.
    - supergarfield 6y ago
      Thanks for the links! I wasn't aware of the PyMem_ layer above, the justification for that does sound bad. But Python runs a generational GC in addition to refcounting to catch cycles (https://docs.python.org/3/library/gc.html https://docs.python.org/3/library/gc.html): isn't fine control over allocation necessary for that? E.g. to efficiently clear the nursery?

loeg 6y ago

Even higher-performance mallocs like jemalloc had heap debugging features (poisoning freed memory) before Heartbleed, which -- if enabled -- would catch use-after-frees, so long as libraries and applications didn't circumvent malloc like OpenSSL did (and Python still does AFAIK).

supergarfield 6y ago
> and Python still does AFAIK Don't you sort of have to do that if you're writing your own garbage collector, though? I guess for a simple collector you could maintain lists of allocated objects separately, but precisely controlling where the memory is allocated is important for any kind of performant implementation.
- loeg 6y ago
  Python does refcount-based memory management. It's not a GC design. You don't have to retain objects in an internal linked list when the refcount drops to zero, but CPython does, purely as a performance optimization. Type-specific free lists (just a few examples; there are more): * https://github.com/python/cpython/blob/master/Objects/floatobject.c#L231-L245 https://github.com/python/cpython/blob/master/Objects/floato... * https://github.com/python/cpython/blob/master/Objects/tupleobject.c#L268-L290 https://github.com/python/cpython/blob/master/Objects/tupleo... And also just wrapping malloc in general. There's no refcounting reason for this, they just assume system malloc is slow (which might be true, for glibc) and wrap it in the default build configuration: https://github.com/python/cpython/blob/master/Objects/obmalloc.c#L733-L771 https://github.com/python/cpython/blob/master/Objects/obmall... So many layers of wrapping malloc, just because system allocators were slow in 2000. Defeats free() poisoning and ASAN. obmalloc can be disabled by turning off PYMALLOC, but that doesn't disable the per-type freelists IIRC. And PYMALLOC is enabled by default.
  - supergarfield 6y ago
    Thanks for the links! I wasn't aware of the PyMem_ layer above, the justification for that does sound bad. But Python runs a generational GC in addition to refcounting to catch cycles (https://docs.python.org/3/library/gc.html https://docs.python.org/3/library/gc.html): isn't fine control over allocation necessary for that? E.g. to efficiently clear the nursery?