Do not use RTLD_DEEPBIND if dlmopen is available #18612

danog · 2025-05-21T12:58:45Z

This pull request disables usage of RTLD_DEEPBIND if dlmopen is available.

Context:

Php8.1 with alternative malloc allocators #10670 - The issue this PR fixes, using RTLD_DEEPBIND with custom allocators preloaded via LD_PRELOAD causes segfaults as the main binary is using the custom malloc, while shared libs use the global malloc due to RTLD_DEEPBIND
Add --enable-rtld-deepbind configure flag, disable it by default except for apache #16779 - My previous PR which disables RTLD_DEEPBIND only on non-apache SAPIs via autoconf at buildtime, which raised some questions when building multiple SAPIs
Php8.1 with alternative malloc allocators #10670 (comment) - Context as to why RTLD_DEEPBIND was initially added, to avoid symbol conflicts with already loaded libraries when using the embed SAPI for example via apache.

After careful consideration, I believe this is the best approach, after considering the following alternatives:

Making a PR based on Add zend.dlopen_deepbind php.ini directive #11094, disabling deepbind by default via an ini default except when using the embed SAPI, changing the ini value in php_embed_init; this is still SAPI-dependent behavior, which will still cause the same segfaults if jemalloc is used with the embed SAPI.
Writing a wrapper for the embed SAPI which dlmopens the real libphp.so within a new namespace (essentially what @dstogov intended with his suggestion, except with RTLD_DEEPBIND the isolation is not propagated, with dlmopen namespaces it is)

I opted for the much cleaner approach of completely disabling RTLD_DEEPBIND if dlmopen with LM_ID_NEWLM is available, leaving to users the resposibility of isolating libphp.so when including it by using dlmopen(LM_ID_NEWLM, "libphp.so", RTLD_LAZY); instead of dlopen("libphp.so", RTLD_LAZY|RTLD_DEEPBIND);.

dlmopen provides full recursive isolation for all symbols both in the opened library, and in libraries opened by that library, avoiding symbol conflict issues even more effectively than RTLD_DEEPBIND, which is not recursive.

On platforms where GNU extensions aren't available (and dlmopen thus isn't available), RTLD_DEEPBIND is left enabled; if equivalent namespace isolation methods are available on other platforms, they can be added with later pull requests if needed.

Zend/zend_portability.h

danog · 2025-05-28T11:21:41Z

Ping? :)

danog · 2025-05-29T17:56:43Z

After some more testing, noticed that since full isolation via dlmopen of libphp.so with LM_ID_NEWLM can completely replace DEEPBIND in the sense that it avoids conflicts even better than DEEPBIND does, it has the side effect that isolation can't be enabled on the user side with the apache sapi, as it explicitly requires apache symbols from the parent scope of the executable (I initially assumed this wasn't the case).

Fixed this by re-enabling deepbind only when the apache SAPI is enabled, checking via a SAPI module property instead of at compile-time, to avoid issues when building multiple SAPIs at the same time (this is not the case in most distros, but is still supported by the build system, so leaving it like this).

Ping @iluuu1994 for a review :)

sapi/apache2handler/sapi_apache2.c

bukka

I wonder if it should be also enabled for embed and possibly lightspeed as well.

main/SAPI.h

danog · 2025-06-01T14:25:09Z

Re: embed, no, deepbind does not need to be enabled for it to be usabile via dlmopen, as the embed SAPI alone only exports symbols, and only when the apache SAPI is enabled some symbols are imported.

Re: litespeed, its SAPI is built as a standalone executable so it shouldn't need deepbind.

dstogov

See my comments. I think, they should help making the patch more consistent and simple.

Zend/zend_extensions.c

Zend/zend_portability.h

Zend/zend_extensions.c

main/SAPI.c

Zend/zend_globals.h

nielsdos

In general, I think this is a neat approach. Please see my questions/comments

nielsdos · 2025-06-09T11:48:37Z

Zend/zend_extensions.c

@@ -19,6 +19,7 @@

 #include "zend_extensions.h"
 #include "zend_system_id.h"
+#include "SAPI.h"


You still have this include, but I don't understand why you still need this?

nielsdos · 2025-06-09T12:15:33Z

sapi/phpdbg/phpdbg_prompt.c

@@ -19,6 +19,7 @@
 #include <stdio.h>
 #include <string.h>
 #include "zend.h"
+#include "main/SAPI.h"


Why did you add this include? I removed it and it still compiles. Same question for the other SAPI files.

It still fails here and elsewhere if removed (though not locally on my glibc linux machine either): https://github.com/php/php-src/actions/runs/15554443234/job/43791709784?pr=18612

I understand. That's unfortunate.
The portability include should not require the SAPI header.
Going via CG() globals (or alike) is better but I see this had issues on ZTS. Not sure how to fix this at this moment. I may be able to take a look later this week.

Hmm, I don't quite see why is requiring the SAPI header such a dealbreaker; granted, it should probably be included by zend_portability.h directly (though that's a bit trickier to do), but even if included separately it shouldn't be an issue IMO

Ping for tomorrow :)

If it depends on the SAPI header (and only that one really), maybe ... it should be defined in the SAPI header instead now?

If it depends on the SAPI header (and only that one really), maybe ... it should be defined in the SAPI header instead now?

I think that's wrong too. The macro abstracts away loading the library on different plaforms, so clearly it belongs to zend_portability.h

I wonder if it isn't even better to have a true process-wide global variable instead? No more trouble with CG(...) in ZTS and no dependency on the SAPI level...

Agree, a new static variable is better than making this part of sapi_module.

This reverts commit 7d59f7c.

…e_dlmopen

bwoebi · 2025-06-19T12:31:40Z

Zend/zend_API.c

@@ -40,6 +40,8 @@
 /* these variables are true statics/globals, and have to be mutex'ed on every access */
 ZEND_API HashTable module_registry;

+bool use_deepbind = false;


This must be ZEND_API to use the symbol within DL_LOAD() from extensions.

I'd call it also zend_dl_use_deepbind. The reason being that public symbols normally need to be prefixed by zend_ or php_ (depending on where it is) and the "dl" in the prefix makes it clear it's about dynamic loading.

danog · 2025-06-19T13:26:17Z

Not sure about the causes of the windows failure, the UNIX build seems to use the same inputs to the linker...

bwoebi · 2025-06-19T13:32:36Z

@danog Not sure, but I believe these extern declarations also need ZEND_API.

bukka · 2025-06-19T14:01:06Z

sapi/apache2handler/sapi_apache2.c

@@ -461,11 +461,14 @@ static int php_pre_config(apr_pool_t *pconf, apr_pool_t *plog, apr_pool_t *ptemp
 	return OK;
 }

+ZEND_API extern bool use_deepbind;


Wouldn't work if this was wrapped to some functio (e.g. zend_use_deepbind() that would set such variable in zend code). I don't mind the Zend part but it's not exactly nice API for SAPI...

Do not use RTLD_DEEPBIND if dlmopen is available

fe18f08

github-actions bot added Category: Engine ABI break labels May 21, 2025

danog mentioned this pull request May 21, 2025

Add --enable-rtld-deepbind configure flag, disable it by default except for apache #16779

Closed

dstogov reviewed May 26, 2025

View reviewed changes

Zend/zend_portability.h Show resolved Hide resolved

Re-enable RTLD_DEEPBIND when on apache for a different reason

ced06f8

github-actions bot added Category: Build System SAPI: apache2handler labels May 29, 2025

Use a sapi config instead

5919d0b

danog requested a review from bukka as a code owner May 29, 2025 17:51

Add missing include

e4297b0

Bilge reviewed May 31, 2025

View reviewed changes

sapi/apache2handler/sapi_apache2.c Outdated Show resolved Hide resolved

CS

d8bb1aa

bukka reviewed May 31, 2025

View reviewed changes

main/SAPI.h Outdated Show resolved Hide resolved

Add missing includes

fe761cc

github-actions bot added Extension: standard SAPI: litespeed SAPI: phpdbg labels Jun 1, 2025

danog added 2 commits June 1, 2025 16:26

Fix

9f749bc

Switch to flags

8292577

dstogov reviewed Jun 2, 2025

View reviewed changes

Zend/zend_extensions.c Outdated Show resolved Hide resolved

Zend/zend_portability.h Outdated Show resolved Hide resolved

github-actions bot added the Extension: ffi label Jun 2, 2025

dstogov reviewed Jun 2, 2025

View reviewed changes

Zend/zend_extensions.c Outdated Show resolved Hide resolved

dstogov reviewed Jun 2, 2025

View reviewed changes

main/SAPI.c Outdated Show resolved Hide resolved

dstogov reviewed Jun 2, 2025

View reviewed changes

Zend/zend_globals.h Outdated Show resolved Hide resolved

danog force-pushed the disable_deepbind_use_dlmopen branch from 3ebc822 to 8292577 Compare June 3, 2025 10:39

danog mentioned this pull request Jun 9, 2025

Do not delete main chunk in zend_gc #18756

Closed

nielsdos requested changes Jun 9, 2025

View reviewed changes

danog added 6 commits June 10, 2025 10:25

Remove unneeded SAPI include

7d59f7c

Revert "Remove unneeded SAPI include"

a21c3e4

This reverts commit 7d59f7c.

Bump

c527785

Merge remote-tracking branch 'origin/master' into disable_deepbind_us…

f368a31

…e_dlmopen

Cleanup

680a887

Test

77a3e9d

bwoebi reviewed Jun 19, 2025

View reviewed changes

Fixup

990316e

danog added 2 commits June 19, 2025 15:41

Test

2892cbd

Fix typo

b6c6e5d

bukka reviewed Jun 19, 2025

View reviewed changes

Do not use RTLD_DEEPBIND if dlmopen is available #18612

Are you sure you want to change the base?

Do not use RTLD_DEEPBIND if dlmopen is available #18612

Conversation

danog commented May 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

danog commented May 28, 2025

Uh oh!

danog commented May 29, 2025

Uh oh!

Uh oh!

bukka left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

danog commented Jun 1, 2025

Uh oh!

dstogov left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

nielsdos left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bwoebi Jun 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

danog commented Jun 19, 2025

Uh oh!

bwoebi commented Jun 19, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

danog commented May 21, 2025 •

edited

Loading

bwoebi Jun 19, 2025 •

edited

Loading