From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2111.outbound.protection.outlook.com [40.107.20.111]) by sourceware.org (Postfix) with ESMTPS id 9C506385783F for ; Thu, 23 Mar 2023 11:06:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9C506385783F Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=microsoft.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=microsoft.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Yad2Gxfe1aNIWvtq6TWXyj124bZ4X+zWSEelZ43TQSLEJ8OBmaDN2D/IYPOn0XpM4NF1JVMlUTeSkWm0s2RCn/vS2Dwpj6RqyH9gMYzjSxQNJhjgYdGIL1XTlZHWPUkf64t4byzAlJN4p3g953GzHLpzSIULh5Jn11c35830k//MsXARbBvxAJidObiDTXulSrpozUQU67bdb4YDhozVwBngChFt5sKAFXjUgpcx6BRGrNq7DMfvtTRNouANwjtLpCsiRE7Ks1mpBIN429tVfVEsRxUO7m0Z6mtldauRa40Xp694Fxwoe1uqk0vqNTqL/vyjuHD8YLxPwPoDENuUqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=z5ImB3BU8+t+y/rKSuNjOxZFHkiiAzTO4Jey1hvlaes=; b=LqR2ibBktWCP7TIk+EDR10FhNgmJYCOfpCnHlqM5V64y/SQ+h5s65kYtAQz8oCtn8fw3Zb4yJpKmVTFKrSt3E26hhJhCL4d45cxfQowNY7wYrpI8lUBNAzEhZX9GPx2nr/eWDVNIsRQSEX+yTBcathsOFUDXvP3KSqMuyZaz8UxU0zmjb9S0Iztql5MaHExJ2nEP3c9sF+pQxsAtsbGFKfeHhSNU3CLxypaKR98cmfmgxvIVRHL8CYolM7JbALHOk5vkZy7piYenqtB2upY7Q1HIExMfYB/2QHEvz17abIPZYEUZpb0hGDMN1ptSLlW9iMpIjLklWa+4LiI2F13wig== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=z5ImB3BU8+t+y/rKSuNjOxZFHkiiAzTO4Jey1hvlaes=; b=Dtuzdev1P/z64sHCTF6/HCbG/MafxqMbCh4iTc88lLEgVy2ijnMF9fZCJlQQJ1Cx9ySrWK9a/9crAEFX6HXtSkfMBIs3WlYATfosZC3RCVjJUsBMDYWGRJryvMHtfbyLCK2O10zxeMEUPK1cM2b3SyhVirNUkZ9ME9S4ZLBBCf8= Received: from PR3PR83MB0474.EURPRD83.prod.outlook.com (2603:10a6:102:7b::8) by AS4PR83MB0523.EURPRD83.prod.outlook.com (2603:10a6:20b:4f1::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6222.10; Thu, 23 Mar 2023 11:06:18 +0000 Received: from PR3PR83MB0474.EURPRD83.prod.outlook.com ([fe80::cd99:d460:c9bf:9de0]) by PR3PR83MB0474.EURPRD83.prod.outlook.com ([fe80::cd99:d460:c9bf:9de0%9]) with mapi id 15.20.6254.006; Thu, 23 Mar 2023 11:06:18 +0000 From: Matthew Parkinson To: "libc-alpha@sourceware.org" Subject: RTLD_DEEPBIND interaction with LD_PRELOAD Thread-Topic: RTLD_DEEPBIND interaction with LD_PRELOAD Thread-Index: AQHZXXULaKW4si6xqUa4s4HUHrseXw== Date: Thu, 23 Mar 2023 11:06:18 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2023-03-23T10:48:46.5243654Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=microsoft.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PR3PR83MB0474:EE_|AS4PR83MB0523:EE_ x-ms-office365-filtering-correlation-id: 2132f996-1855-498e-1dcd-08db2b8ea0ad x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2whKUM0tJf8jdU1wihUlpBHFWC2utq3lM2KXYDgy3BnGFOXj5fxpD8wigWS9ZXfyQq3jzSnhh0Xt4yZzVaXp1xG63FFKzi9kzTOzd5PFwSlJh2BvoT9qn+ThmFhWsGN4/RX1ltF+yHru3j7nfVdXM8vpp6Q924MDw1aQLyi363HqX2GuMsX1n503u/mRTJXLh/SLe5TNtXLENVAkBXQIungQktpF1cTAXIUGG9szn3YxEsNQkcUP24V7wlM+xMFM8gMjX3KplmPKSM5w8AV2ol/2qTAxCW8REBGBGSSyC/RGEsQtDVvk+ialFj49U4UuP9SgPM5wq14FN4Q3xv2cF7pmYfAmmJraIoE7SLyRo/vbEpHReZorDF0V9BuywU1a+sOlzqkj6b6kvbn0c4prxPUi86i2PVuwd8liL2WaeTaKzt6myxBJbxfY4PmcHXcBXP9KXKaOkkemzU6LFWOu9cvTu1EzymZDaClXMtLtoI16xb0lR/XiRelaREkm7u8nRjEbRmgmiZol9p1cx0Oz0IloSvlkCoYC+P7Lnk6cuDQIP43/5Pb86uyW9Hu0+5lojQ+nEbMCJEF+14J4GZWeQDGkR6m65GZvlYjXnyzm/HZ5NR/vuXZWi+2aNJ2kjUcJcKgp7v3orsL377HO2zrOtbPKSsHwEdOYn4i+jq7hbn4VwIwpo3JK5HTOYmL0gTFE x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PR3PR83MB0474.EURPRD83.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230025)(4636009)(136003)(366004)(396003)(39860400002)(346002)(376002)(451199018)(38070700005)(8990500004)(38100700002)(166002)(6916009)(8676002)(82950400001)(82960400001)(66446008)(64756008)(76116006)(66476007)(66556008)(66946007)(186003)(122000001)(9686003)(5660300002)(6506007)(26005)(2906002)(52536014)(8936002)(41300700001)(316002)(7696005)(33656002)(86362001)(55016003)(83380400001)(10290500003)(71200400001)(478600001);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?2FWyLKHbBube5pHPxfjqsLF3k0LmJ3RiIwBfO/FZQDimSl5uYH8a7JEE?= =?Windows-1252?Q?xDQAcL4oYFV3Xw66xsBdRjUSuzZHw4f4xEELWGGmPSXGiAgcQ8XCsyQ5?= =?Windows-1252?Q?0gUf8jPw6y+6xahNav2ZdN36MzpQtobQ1oVUeczeVZ3kMgzsp3jaDAnW?= =?Windows-1252?Q?Dcn+N+r6bjGhiBEAUvWlss2eYDtUXS0lw2WGqBVQCR1ig1fU09uaUj2J?= =?Windows-1252?Q?4/Fys0kLmplMWdB0puls/Uzqa4iINS/ooJ5GygPt7mpgZgkgfq+rqYLR?= =?Windows-1252?Q?IFB6j0pF75UYbjtwrUBwg65h9i6ZQ8uZ29Kn9FjEzC5mYw8VZKNwP7VY?= =?Windows-1252?Q?Mq6ewTX8FOGa0MiNapRpxx4m47UjuS8at5kThC0MSCIPvwXG8DaidPyM?= =?Windows-1252?Q?Y8VJ/Nxwyvxqo1m1SP0unUeVCG8V5kR8+CzUdo5VDFtB/BQrx4nHAEDP?= =?Windows-1252?Q?ns0Arwk6X1Ih9wM/j572fa5hzEuriU6CieewpGAKFtWIutA1m+4mjRab?= =?Windows-1252?Q?sdT1z8AUoEh/2HQ8QSfEz/bfK2xV5ZhAzDQJFUJyK4tc0R6BRp5dU7gb?= =?Windows-1252?Q?v+MvhdRayOz4iroTF9qZ3CAxgldcAnNqRwM4T86RdQYi59wWIHlOxC01?= =?Windows-1252?Q?oujuoTLmOVe/Hwoo5tqgY3uD4zmjTS6BCAKkbZfqzRPbjsUqigIEA5sJ?= =?Windows-1252?Q?zljEPVryBD/qy9NX+ukqoRDb5zaHBvtfnMHDkDLJBi2N+RRcjv8ltUL9?= =?Windows-1252?Q?kUik/HnyUOukiWikGprTtoby7jxjJKkoiQ62qywsaVLnu+WNuXXREpEs?= =?Windows-1252?Q?9JT14j2hBS+ASeLHPwKVkMFBzcGV7OVICfWW9Z62fww2o9Vul6HLn4/W?= =?Windows-1252?Q?Ow5FNvuTcvTJ0qdXD9k8iLQGfaFpiKNBCC2cYTxVKDhx8EyjYlWgYya6?= =?Windows-1252?Q?jYxN+ItiobjaVmC8iuVJ7gYFklTaKE58M9ZW4XQnidg664lnMuTzgJWK?= =?Windows-1252?Q?UWT592mXpBqO5dZjl2+1ah67WWx9xNJnQoK6XrmwrZi74vEDcWUowc7H?= =?Windows-1252?Q?U40P4oOp3r07OtpCwx9rKPJba6iW6N0j+yxkPF7MDTD4gXAK0TtUmnKz?= =?Windows-1252?Q?I3a0ekxKHoE0L/8DDNDUUqQ/bxAn59Aa3TuZqKnOOF6xs2HngRfxoO/n?= =?Windows-1252?Q?HYfQjbR1YjPWRCUGxjPbCG0zSfjNTwvaNTZ6RKJbUrpvntbAPPqRbxH3?= =?Windows-1252?Q?oLrx4Ir7CS/NfdKMh4EATklXA6YUJn5qnqMXSfgrIbV2qFYB1D4JwJLr?= =?Windows-1252?Q?NpHYMM7nlq9b6SGnmptaOBGnlW5QL1piduu+mj8g1M80qEO+sEBn4+rD?= =?Windows-1252?Q?GXB3OeEl1OaG7cSq9a8Df7+Pb8oiO2E6DJ8WPiEZlKZOAxzq+2cNF10N?= =?Windows-1252?Q?KQsVouCuU6JOGCRZAdrnZ3TgW99ymup4S2s0Ju+zy7b302U9QPEqzs/r?= =?Windows-1252?Q?0WC68P28Mvn/AdtFfJe8thFyAzu5fI1AxFjM3+3AQjcRd541f2ykzemx?= =?Windows-1252?Q?qE3SCudIaSStc7m/X0vfO1wmTntQbukL/EE0C7cqatYbrOSPGPQg6C4A?= =?Windows-1252?Q?4HBlSP+/6rb0DNfVc5Tl1H6eLlw8/08aku+hdNWvYxTppNruniIZMZHa?= =?Windows-1252?Q?JJSITD+a0i1vPJxOutQmsSDRKs9C3dgBwf4rL5Lcrwmkeu/IYrFFKA?= =?Windows-1252?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_PR3PR83MB0474EC00EB327AB21C665D5DC5879PR3PR83MB0474EURP_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PR3PR83MB0474.EURPRD83.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2132f996-1855-498e-1dcd-08db2b8ea0ad X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2023 11:06:18.3517 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TUn/WIklPB8CJlFDky64Imy+604z39f9iDLFTfbXIw9gcnXF8NTwd87jIuWsF0qIupuGeBGZ+ToIgNgODp1wug== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR83MB0523 X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --_000_PR3PR83MB0474EC00EB327AB21C665D5DC5879PR3PR83MB0474EURP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable When a shared library is loaded using RTLD_DEEPBIND, it does not use the LD= _PRELOADed libraries in preference. This means that allocator overriding w= ith LD_PRELOAD in applications that load libraries with RTLD_DEEPBIND does = not work. A minimal example can be found here: deepbindexample/problem at main =B7 mjp41/deepbindexample =B7 GitHub This causes issues for a collection of allocators and address sanitizer. Mo= re examples can be found on the Bugzilla issue I raised: 30186 =96 RTLD_DEEPBIND interacts badly with LD_PRELOAD (sourceware.org)<= https://sourceware.org/bugzilla/show_bug.cgi?id=3D30186> And the twitter thread: Twitter thread on RTLD_DEEPBIND I am raising this on libc-alpha to discuss possible solutions, and how acce= ptable each would be to the community. This is the list I have so far from= discussions with colleagues and feedback from Adhemerval Zanella and Siddh= esh Poyarekar: 1. Malloc only solutions * Introduce new malloc specific symbols for LD_PRELOAD * Use malloc tunables to specify the allocator 2. General solutions * Change RTLD_DEEPBIND to look at LD_PRELOADed libraries first * Introduce new environment variable LD_PRELOAD_OVERRIDE_DEEPBIND(*)= that must be respected by RTLD_DEEPBIND * Introduce new RTLD_DEEPBIND_RESPECT_PRELOAD(*) that looks at LD_PR= ELOAD first. (*) Naming is not my strong point, just trying to be illustrative. As an allocator person I am fine with something from =93Malloc only solutio= n=94, but I also appreciate anything that is added is something that needs = to be maintained. So a quick specific solution may be a long-term bad choi= ce. The =93General solutions=94 has far more ramifications that I personal= ly don=92t understand. Here are some more details of the specific ideas 1a. This is probably the quickest solution. Introduce a collection of int= ernal symbols that are used to override the allocator. I have put a very mi= nimal PoC for a single call at: deepbindexample/solutionopt at main =B7 mjp41/deepbindexample =B7 GitHub<= https://github.com/mjp41/deepbindexample/tree/main/solutionopt> The core idea for something exposed would be __attribute__((visibility("hidden"))) void message_impl() { puts("lib.c: message_impl"); } __attribute__((weak)) extern void override_message(); extern void message() { if (override_message !=3D NULL) { puts("lib.c: message -> override_message"); override_message(); return; } puts("lib.c: message -> message_impl"); message_impl(); } Here `message` would be the libc function we want to be able to override. = A library that wants to override this would provide both `message` and `ove= rride_message`. This would then work even in the presence of RTLD_DEEPBIND= libraries. The call from a library that was loaded with RTLD_DEEPBIND wou= ld call the libc `message`, which would then call the `override_message` fr= om the preload. This incurs a single load, compare and branch on the fast path when LD_PREL= OAD does not occur. It does not suffer the previous malloc hooks issues as= this is a relocation, rather than a code pointer in the data segment. 1b. This is proposed by Siddhesh Poyarekar. I think the idea is to expose = a =93Tunable=94 parameter to specify, which malloc library to use. This is= very appealing and has a clear meaning to me. I worry a bit about when Tu= nables are processed and if any allocation occurs before then. 2a. This seems like the nicest solution if RTLD_DEEPBIND didn=92t already e= xist. It will alter existing semantics of programs, and hence is probably = a compatibility nightmare. 2b and 2c. Are both adding a new feature to enable the desired behaviour. = Personally, I prefer 2b as that doesn=92t require everything that currently= uses RTLD_DEEPBIND to be modified. However, I do not have enough experien= ce to understand the consequences of either choice properly. I am sure there are other possible approaches not outlined here, and I am s= ure there are consequences of each choice that I am not aware of. However,= I do believe making LD_PRELOADing an allocator more reliable is an importa= nt feature for glibc. -- Matthew Parkinson, Principal Researcher Microsoft --_000_PR3PR83MB0474EC00EB327AB21C665D5DC5879PR3PR83MB0474EURP_--