martin luther wrote:
should we implement
https://github.com/GrapheneOS/hardened_malloc/
it is hardened memory allocate it will increase the security of fedora
according to the graphene os team it can be ported to linux as well need
to look at it
There are several questions that come up:
* Against what exact threats does this protect? Use-after-free? Heap buffer
overflow? Others?
* How does it relate to _FORTIFY_SOURCE? Can they be used together? (If not,
it might actually reduce rather than increase the security of Fedora.)
* How does it perform, both in terms of speed and memory consumption
(overhead)? Better or worse than the glibc malloc? (If it is much worse than
the glibc malloc, it is not going to be a suitable default for Fedora.)
* How does it compare to the glibc malloc in terms of quality of
implementation issues, such as that realloc should avoid copying the whole
block whenever an in-place resize is possible?
* Can hardening be added to the existing glibc malloc implementation or is a
complete rewrite as the suggested one really needed?
* How do you suggest it getting used distro-wide instead of the glibc
implementation? Upstream's suggestion is to link it as an additional dynamic
shared object, so then the order of linking is important, and you also have
to take care to link it into all applications (and there are lots of build
systems out there). The alternative, I suppose, would be to modify glibc.
Kevin Kofler