From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 4C4B23858C78; Wed, 8 Mar 2023 20:41:30 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4C4B23858C78 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1678308090; bh=Qrs8OdXZ1iM75j4IgI/jxpHCSvIB+Um6xsZ7KwDEKy4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Z+TQJtffCcnrRgD3sVuuzKtBcHlH6+lxUST8n49o5uTPvz0HPIS1DdVJok16d5ydl fTl1HRdCeXQPCtcSMwVpr7PiXJ0CxzBBSdXlkPjp63bNIrtHkWH9McgFrGDmkFcB6c sbbScqvWLXH/gd64vS0vs13QP9wTmOGKdf09LunU= From: "parky at outlook dot com" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/30186] RTLD_DEEPBIND interacts badly with LD_PRELOAD Date: Wed, 08 Mar 2023 20:41:29 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: parky at outlook dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30186 --- Comment #2 from Matthew Parkinson --- So based on a suggestion from a colleague Paul Lietar, we have an alternati= ve suggestion that is less invasive.=20 Previously, the malloc hooks provided a layer of indirection which has now = been removed. We wonder if you could reintroduce the layer of indirection but o= nly accessible to the loader. If you make=20 extern void* malloc(size_t s) { return __libc_malloc(s); } Now, if you prevent inlining of __libc_malloc, then you can expose __libc_malloc as something that can be overridden by LD_PRELOAD. As an RTLD_DEEPBINDed library would call malloc, this would immediately jump to w= hat ever symbol exists for __libc_malloc, when libc was loaded, and this would account for LD_PRELOAD. I have an example that suggests this could work: https://github.com/mjp41/deepbindexample/tree/main/solution Many allocators already provide symbols for __libc_malloc, e.g.: https://github.com/microsoft/mimalloc/blob/dd7348066fe40e8bf372fa4e9538910a= 5e24a75f/src/alloc-override.c#L273-L285 https://github.com/jemalloc/jemalloc/blob/09e4b38fb1f9a9b505e35ac13b8f99282= 990bc2c/src/jemalloc.c#L3143-L3175 So these would just start working with RTLD_DEEPBIND. The obvious question is how much performance would be lost in adding the indirection. It would not affect existing allocator overrides as they could override both, but for programs using the libc allocator, there would be a cost. I am sure there are many complexities that I am missing, but I thought this= is worth mentioning. --=20 You are receiving this mail because: You are on the CC list for the bug.=