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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
