8:52 a.m.
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.