On Tue, Jan 15, 2019 at 11:48 AM Stefan Sperling <s...@stsp.name> wrote:
>
> On Tue, Jan 15, 2019 at 11:19:24AM +0100, Stefan Eissing wrote:
> > Would OpenBSD be happy with a setting (COMPILE FLAG) that forces
> > the immediate free() by allocators and otherwise skipping the DEBUG
> > flags?
>
> Yes, I think that would be great. I don't care about the pool debugging
> aspects as much as the benefits we get from direct use of our nalloc/free.
How about "MaxMemFree 1" in OpenBSD's httpd then instead of compile
time APR_POOL_DEBUG?
A patch could help enforcing this, something like:
Index: server/mpm_common.c
===================================================================
--- server/mpm_common.c (revision 1851349)
+++ server/mpm_common.c (working copy)
@@ -151,7 +151,9 @@ AP_DECLARE_DATA int ap_graceful_shutdown_timeout;
AP_DECLARE_DATA apr_uint32_t ap_max_mem_free;
AP_DECLARE_DATA apr_size_t ap_thread_stacksize;
+#ifndef ALLOCATOR_MAX_FREE_DEFAULT
#define ALLOCATOR_MAX_FREE_DEFAULT (2048*1024)
+#endif
/* Set defaults for config directives implemented here. This is
* called from core's pre-config hook, so MPMs which need to override
@@ -377,6 +379,7 @@ AP_DECLARE(const char *)ap_mpm_set_graceful_shutdo
const char *ap_mpm_set_max_mem_free(cmd_parms *cmd, void *dummy,
const char *arg)
{
+#ifndef __OpenBSD__
long value;
const char *err = ap_check_cmd_context(cmd, GLOBAL_ONLY);
if (err != NULL) {
@@ -392,6 +395,9 @@ const char *ap_mpm_set_max_mem_free(cmd_parms *cmd
ap_max_mem_free = (apr_uint32_t)value * 1024;
return NULL;
+#else
+ return "MaxMemFree can't be used on OpenBSD";
+#endif
}
The first hunk is probably something that can be upstreamed (for "-D
ALLOCATOR_MAX_FREE_DEFAULT=1" to be usable at build time), the second
hunk is up to you...
>
> > Personally, I would like that to be the default behaviour in httpd. The
> > current implementation seems to hinder use of modern address sanitation
> > tools and fuzzing. Something which has proven very valuable in h2.
I disagree for the default, it's a trade off as always.
>
> Agreed. Note that OpenBSD's malloc/free provide a degree of instrumentation
> similar to address sanitizer. This behaviour is tunable, and the default mode
> is not the most aggressive one. But when applications don't call free when
> they no longer use a chunk of memory, such instrumentation built into the
> system cannot work. See https://man.openbsd.org/malloc#MALLOC_OPTIONS
OpenBSD trades performance for its level of security, but it's not the
main concern for every one.
I'm still waiting for an OS allocator as performant as APR (or
another) pool allocator, different constraints between the two of
course. The OSes themselves use pool/bulk allocation internally when
performance matters...
PS: Stefan/icing, I'm happy to help with POOL_DEBUG , not much spare
time lately (new day job$) but I can try...
