On Wed, Sep 07, 2022 at 08:39:56AM -0700, John Reiser wrote: > On 9/5/22 19:45, Daniel Micay wrote: > > On Wed, Aug 31, 2022 at 10:19:51AM -0700, John Reiser wrote: > > > > Bottom line opinion: hardened_malloc ... costs too much. > > > > > > Attempting to be constructive: Psychologically, I might be willing to pay > > > a "security tax" of something like 17%, partly on the basis of similarity > > > to the VAT rate (Value Added Tax) in some parts of the developed world. > > > > The comparison is being done incorrectly. Since hardened_malloc builds > > both a lightweight and heavyweight library by default, > > That claim is false. You're not following the official approach to packaging and installing hardened_malloc. It has 2 official build configurations and packaging that's done properly includes both. We don't currently define other configurations, but we could define a 'lightest' one too. I've given both concise and detailed explanations here, which you've gone out of the way to ignore. The Makefile for commit 72fb3576f568481a03076c62df37984f96bfdfeb > on Tue Aug 16 07:47:26 2022 -0400 (which is the HEAD of the trunk) begins > ===== > VARIANT := default > > ifneq ($(VARIANT),) > CONFIG_FILE := config/$(VARIANT).mk > include config/$(VARIANT).mk > endif > > ifeq ($(VARIANT),default) > SUFFIX := > else > SUFFIX := -$(VARIANT) > endif > > OUT := out$(SUFFIX) > ===== > and builds only one library, namely $OUT/libhardened_malloc$SUFFIX.so > which for the case of "no options specified" is out/libhardened_malloc.so . > > If would be better for external perception if the name "libhardened_malloc.so" > were changed to something like "libhardened_malloc-strong.so". > Having both -strong and -light versions built every time > would highlight the difference, and force the user to decide, > and encourage the analysis that is required to make an informed choice. The 2 default configurations are not the only choices. The light configuration still has full zero-on-free and canaries enabled. If we felt like matching or even exceeding glibc malloc performance on microbenchmarks we could add an optional thread cache and a performance configuration but it's not the point of the project at all, and glibc malloc is not a high performance allocator. hardened_malloc can provide similar performance with all optional features disabled vs. glibc malloc with tcache disabled. If hardened_malloc had array-based thread caching added (free lists would lose even the very basic 100% out-of-line metadata security property) then with optional features disabled it would be comparable to default glibc malloc configuration. We're already done extensive testing. There's no thread cache included because it simply isn't within the scope of it. It's a hardened allocator, and a thread cache bypasses hardening and makes invalid free detection, randomization, quarantines, and other features not work properly. It has been tested with a thread cache. We know the impact of it. I don't think it makes sense to use it with one. > > already explained this and that the lightweight library still has > > optional security features enabled, it doesn't seem to have been done in > > good faith. My previous posts where I provided both concise and detailed > > information explaining differences and the approach were ignored. Why is > > that? > > > > As I said previously, hardened_malloc has a baseline very hardened > > allocator design. It also has entirely optional, expensive security > > features layered on top of that. I explained in detail that some of > > those features have a memory cost. Slab allocation canaries have a small > > memory cost and slab allocation quarantines have a very large memory > > cost especially with the default configuration. Those expensive optional > > features each have an added performance cost too. > > > > Measuring with 100% of the expensive optional features enabled and > > trying to portray the performance of the allocator solely based on that > > is simply incredibly misleading and disregards all of my previous posts > > in the thread. > > I measured the result of building and using with the default options. > Unpack the source, use "as-is" with no adjustment, no tweaking, no tuning. > If the default source is not appropriate to use as widely as implied > by the name "malloc" (with no prefix and no suffix on the subroutine name), > then the package is not suitable for general use. > Say so immediately at the beginning of the README.md: "This software > is not suitable for widespread general use, unless adjusted according to > the actual use cases." The hardened_malloc project is perfectly suitable for general purpose use and heavily preferring security over both performance and memory usage for one of the 2 default configurations doesn't make it any less general purpose. The chosen compromises do not impact whether or not it is a general purpose allocator. Both default configurations are suitable for general purpose, widespread use. GrapheneOS has used the non-light configuration since hardened_malloc was introduced. It performs much better than the previous OpenBSD malloc port. It also performs better than the also general purpose musl malloc-ng heavily focused on low memory usage and low fragmentation. That's a general purpose allocator too and is not any less suitable for widespread usage either. I've added bitwagon.com to the block list for mail.grapheneos.org based on your continued dishonest spin and misinformation. Zero interest in having any further communication. You should consider it a ban from the rest of the GrapheneOS community too. If you ever end up wanting that to be undone you'll need to make up for your behavior here. > > hardened_malloc builds both a lightweight and heavyweight library by > > default. The lightweight library still has 2 of the optional security > > features enabled. None of the optional security features is provided by > > glibc malloc and if you want to compare the baseline performance then > > none of those should be enabled for a baseline comparison. > > > > Take the light configuration, disable slab allocation canaries and full > > zero-on-free, and there you go. > > I reported an end-to-end measurement and comparison based on data. > Where have you reported actual end-to-end measurements and comparisons? We've published posts with detailed information and performance / memory usage comparisons. We've provided detailed information of the cost of the different features and 2 sample configurations based on different balances between memory usage / performance vs. security. The light configuration is not the lightest hardened_malloc configuration, as I've explained previously, and the optional features it enables are not done by jemalloc, glibc malloc, etc. A direct comparison would be to compare hardened_malloc with all optional features disabled vs. glibc malloc with tcache disabled, which is still comparing with a very hardened design with 100% out-of-line metadata, no reuse of address space between size classes and metadata, etc. It is a fair, direct comparison though. If you want thread caching, which you presumably don't if you want even basic hardening, that's easy enough to build on top of hardened_malloc. Maybe I'll add optional thread caching and a predefined performance configuration simply to make it easier to debunk misinformation like what you're spreading. I see no reason for someone to want to use that though. If you want a performance-oriented allocator, you aren't going to be using hardened_malloc, and you also aren't going to be using glibc malloc either, which is not high performance, scalable or low fragmentation and only has being a default with the 2nd most widely used Linux libc going for it. I'm not interested in engaging with a troll any further. I'll likely add bitwagon.com to the mail.grapheneos.org block list if you push any more disingenuous spin and misinformation. Not a problem with me. _______________________________________________ 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
