On 9/5/22 21:02, Daniel Micay via devel wrote:
On Wed, Aug 31, 2022 at 05:59:42PM +0200, Pablo Mendez Hernandez wrote:
Adding Daniel for awareness.
Why was the heavyweight rather than lightweight configuration used? Why
compare with all the expensive optional security features enabled?
The default configuration was used. " ...; make" produces
out/libhardened_malloc.so and no other shared library.
Even
the lightweight configuration has 2 of the optional security features
enabled: slab canaries and full zero-on-free. Both of those should be
disabled to measure the baseline performance. Using the heavyweight
configuration means having large slab allocation quarantines and not
just zero-on-free but checking that data is still zeroed on allocation
(which more than doubles the cost), slot randomization and multiple
other features. It just doesn't make sense to turn security up to 11
with optional features and then present that as if it's the performance
offered.
The use case is a builder and distributor of software packages to a large,
diverse audience. There is concern about the possibility of malware
attacking the build process, a "supply-chain attack". Of course there
are other protections already in place, but the possibility of better
protection is reasonable to investigate. A network search revealed
a dearth of end-to-end performance measurements, and/or comparisons
based on actual data.
I'm here to provide clarifications about my project and to counter
incorrect beliefs about it. I don't think it makes much sense for Fedora
to use it as a default allocator but the claims being made about memory
usage and performance are very wrong. I already responded and provided
both concise and detailed explanations. I don't know what these nonsense
measurements completely disregarding all that are meant to demonstrate.
I reported an actual measurement and comparison of two allocators
using commonly-available tools and a documented, repeatable methodology.
The choice of which two allocators is reasonable for the use case.
> [[snip]]
_______________________________________________
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
