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. 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.
and since I
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."
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?
[[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
