This needs to be disabled for compatibility with the exploit protection
compatibility mode on GrapheneOS. hardened_malloc shouldn't be trying to
initialize itself when exploit protection compatibility mode is enabled.
This has to be handled in our Bionic integration instead.
The safe_flag check doesn't work properly for C++ flags with Clang so
this wasn't getting enabled despite the conditional compilation being
removed from the code, leading to breaking Clang builds.
This makes it harder to miss that an error occurred and avoids spamming
output. There should never be a single error, so it doesn't make sense
to gather as many errors as possible when a single error is already a
serious issue that would need to be fixed.
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.
Daniel Micay
Christian Göttsche
Daniel Micay
jvoisin
rwarr627
Patrick Schleizer