use correct Section: libs rather than misc
compatiblity with dh_dwz / dwz - https://github.com/GrapheneOS/hardened_malloc/issues/85
move to sub folder /usr/lib/libhardened_malloc.so so lintian will not complain
about non-versioned shared objects and missing symlinks. That extra complexity
is not needed here since this lib aims to be compatible with what it replaces.
full path is now /usr/lib/libhardened_malloc.so/libhardened_malloc.so
deprecate no longer needed make_all_hook_post as this was improved in genmkfile
This is a no-op on a toolchain compiled with the basic mitigations
enabled by default, so this is generally a no-op anywhere this project
is likely to be deployed. SSP has a very low performance cost so there's
little reason to avoid it, even though it also has zero value for this
code in practice. It would be great if one of the more modern approaches
was widely adopted, but unfortunately SSP is as good as it gets for
portable options. It doesn't provide any protection against external
writes to the stack data which is all that's really needed here.
ShadowCallStack is a great option for arm64, but it's substantially more
difficult to protect return addresses well on x86_64 due to the design of
the ISA and ABI.
This wouldn't be worth using even if it had a whole bunch of heuristics
like ignoring expressions in static_assert, ignoring repeated patterns
like assigning different things to sequential array indexes, etc.
This extends the size class scheme used for slab allocations to large
allocations. This drastically improves performance for many real world
programs using incremental realloc growth instead of using proper growth
factors. There are 4 size classes for every doubling in size, resulting
in a worst case of ~20% extra virtual memory being reserved and a huge
increase in performance for pathological cases. For example, growing
from 4MiB to 8MiB by calling realloc in increments of 32 bytes will only
need to do work beyond looking up the size 4 times instead of 1024 times
with 4096 byte granularity.