[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#945457: consider using hardened malloc (hardened memory allocator)



control: tag 945457 + wontfix

On 2019-11-25 08:23, Patrick Schleizer wrote:
> Package: glibc
> Severity: wishlist
> X-Debbugs-CC: whonix-devel@whonix.org
> 
> https://github.com/GrapheneOS/hardened_malloc
> 
> 
> > RFP: hardened-malloc -- hardened memory allocator
> 
> > * Package name    : hardened-malloc
> >   Version         : 2.0
> >   Upstream Author : Daniel Micay
> > * URL             : https://github.com/GrapheneOS/hardened_malloc
> > * License         : MIT
> >   Programming Lang: C
> >   Description     : hardened memory allocator
> > This is a security-focused general purpose memory allocator providing
> > the malloc API along with various extensions. It provides substantial
> > hardening against heap corruption vulnerabilities. The security-focused
> > design also leads to much less metadata overhead and memory waste from
> > fragmentation than a more traditional allocator design. It aims to
> > provide decent overall performance with a focus on long-term performance
> > and memory usage rather than allocator micro-benchmarks. It offers
> > scalability via a configurable number of entirely independently arenas,
> > with the internal locking within arenas further divided up per size
> > class. It can be added as a preloaded library using /etc/ld.so.preload.
> 
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945455

It's pretty fine to provide a package with a different memory allocator.
It's also fine if the package uses ld.so.preload to make it the default
system one.

All that said, we have no plans in using a different memory allocator
than the upstream glibc one. Hence tagging the bug as wontfix.

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

Attachment: signature.asc
Description: PGP signature


Reply to: