From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 16337 invoked from network); 1 Jan 2022 13:58:51 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 1 Jan 2022 13:58:51 -0000 Received: (qmail 1374 invoked by uid 550); 1 Jan 2022 13:58:49 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 1340 invoked from network); 1 Jan 2022 13:58:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s2048; t=1641045516; bh=lmcQE4J42/9l/m6FzfLEo5wfPtfyC06HK2qDdERYrTs=; h=Date:From:Subject:To:References:In-Reply-To:From:Subject:Reply-To; b=UZ6ZsEGuj5npX5zhNAwI72kPZY1QxfF0nZCQe04cLnjIoAoJgk9541DvqPXdKPzsbgTfPOausLXoHXSsR47ODkxNuTNXFHON+uYGYa/u0mhp/1CSApBVd1xg2wZzD6gfh646AfeZuUMM/FNnUMDiq5hPRurp9e/7owOuLd3qhw+5xMVA1Tn0NZAqohweHSnmKJyZl8zfquwUOKTf9LzizSPXU+U9Waga112t27JbLnvU7ZXXYjWuXpahSymQyPTU4iIzsVufyfLODQ/0i9br9kN5ioyK+4DMGiM8dGpTbiHrtbqMUAuhlsY7KxehAY5QjqrIvFSjjsqQXJo8WJWiWw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641045516; bh=T6OQ0s/QvgTvtpXiku3VU7oVjvgYhYXrd1adl0GxtwC=; h=X-Sonic-MF:Date:From:Subject:To:From:Subject; b=WPkDm6dtVbbcP+fyrjEy2ywd8wQYPqnb/nT4ndhXAV/mQ3CHwFoLCxJSCRtEtF1CToy2+8u8ubzVvjZCtxjLIAk4fm6b8kpq51OPgRgQLZi7sHZgy+qjXUcNELf/yImjLdudrbTTbwOqELoVdmxmDMell+GhBTZd290F2QKQN5N5mF1k2eVS5J8MXQlAg6y2HktligXAIwpGWVh1R7F5/5loWGPAErHugx8T4atVc45apgEuJpxsewV3LbBO8Bee2TXsm2IljHp7cwlLTevZnp/3FdRWDGoSlY17KztFK1zFvcz6JynB/dOJucOD5BKa8rWMfftaj+GQ4E4Vr0H3ew== X-YMail-OSG: A1p5laEVM1kOIkzmzhsOJOVshiFSUQFxRMxwrozSVPqlN_Vuilc6AVsiaCPcvux S3dAYuRj1WEUZVk8glRslHJTeX6CMyq8usjy6vKnGD1YP8nN9iHA4_NdZcRMJnN8DxRzSxJ.n.bG s_hILNadqHwcoOdHxoc0t6wA5aCSBdWZTlt9gYvG0mJlmDa8FxS.CZfAWcTXNOD3Wj6JWj0xjVVo gzLSAz_IxgO3o3Or0T1ELBCjyuNQsYtZA5QAIuAXgn4bcW0WOkEpwk_u2UyKG4upEMItmlYpGhhh hlLzkUbBpaNdLErqHyr.x2hpIKd2WQvM.BhZ_2esuuqlterWFeoaV.E2ADhi8Au1RUJYQZfGfoC9 BbuSOXarP36WOcZTK4Z2dtqYZjb7IxEQJ7HzZDWfL3xrSRGMxXENGG6ChvcNwzNu1UPHW9z7oBlO vMICjxaBUI6TywzC0OqQ0PjZ97eFyRACjQ4dmKAjgnRJFf7ckjQq_u8NCDwL3hSJEBdYwOCB0GZ9 6DMbeq8sq3QphKPustBtzjvU.Yqe_GZIb_RIpIlFc17YyzPAOQHp8dIV33buFMqZMpXt5u6l8Owu OfBIkwDITPYfPLSV72oAXEP6JEHceClma.00BK2uDp1U78zg722izzk1QpTbWIVfrIGezTYPNjH7 Nlqqa7TSYrxjQYi5.qkSRl46vxc8VDbQvJ6lLI.lZv8xk1p34S13g7KzoSARxZhBoN5jFWWJBXER xpvgEpedCoxE9Or8NljagxbyeQ1Is0ryOxCvrEuYbnIvpbRxsMTufYsGjhCwqRkrapQHdlAe4ydc Wcp7zU5Le2mK5YA65AOAcB5uJMtP71gl7_zdcAtsXu5VuzDB2WSthbQe9WMfgcGalVHBFrCMJTuV 5MF2hnyPErlbITAsoeEw_4EmDqKrYRWm3M.IBH7qdmDYXUFxdoX18QOagevzu68V4zwxvIfuiJeJ N8xGlEMx3fApH4_8nF_DAlbj0BM53bv42MXPsPjlf6Wy4FtD1xorlHljp8oydzOcFODdAS9_nkhb ERTYiXgqim_NUGehHf8z2Iqx5OcKoWtij5t1kVzWz24RpVJjdDtjYbRwlns0O0OfOkj.o_FfBqTh ysvI8o2Bwpc5c69Pn8MW36MLHa3ziKLzfr38noUa3w5qI9l357_ntKja_7G0._O8QAjkYdjOFS2G ly8M9c3UAJhvf3KryFLnlYkvZoZvbzycFHnmPlQ6A6IYWnxrUyGDFGb8AExz4WGXOyveXZKe1GdY FBOPbZU2DTX_AsxCyZEX8QGLdSPZyMH28XhCRLwCGWmc3iBk9Wu5DVz_siZ0_4IV9rGfkUD4xWkG q8UzsK10f5uKYd5QZVyG.dWstraq2x9nsGGOKsHiQPX032laD5BqpCLiqVfzTTmY9hCJUOBUYrCK X873LTI_gZhDh3s2H7y8IDGL8tV7MW1IEnOhA8D7Ov04j4sv7mFCbf7YtM9V4hfVgGFLxybQa0Sv bJaZLE6wgxVegc8dSQu9InAAIJx4ealrfSYCiSNsgdY0..F2rKsY25yH9khIF7POfdb8ZxfUMPUk bZabC5NbigORqtZC24OicG7TrLCRbkCTH4lvZ2EK1yCHyBga3y.0l.ae13rYp_2rpy9e1sLSn9hv fzOK_gDmcwbshbxKSaMF_o1j2iTbmzk87_3cDD56KNsIyIIqjgRy8Krbm.tezYrXPRrBjJFDCHlg Vo3vbt1TvYtuFSYIakJf3z.dIzA24ktyUsXmu1EnOez2oaFSDx9m6KLbxzvehiBvy2eA5NCiphQh b5jGIIhLeMVqbyKp5GKZSvDCBD_TXqW32wIzRNYer5h3SmPyLHmx4YyLgl17gX3UZKVHLrsZGQNE W.0GZ62jHztALbFAh14etIg7QbbhlnBBmPX5SbxGCVOoiGJL36TnZKHgO7oWMRJJZwvDOpVKAYL_ YBohjTI94Ev_V1_PorsSVRFAvbZH.tG2iA1LvT4Nznc9VvWWicyZxV92boU4lGJLDvmrcVxTRsq1 tMExCoE3LGG1cJ5sfpwtyK4kPFnxg67FCi84QRB1rs_0Rrvtwymgm8qxAh35PnVBQpskPzEWfMnF .PvnAVyxZYjc222bMzpeYXAznLY6_c5msvd5z6cdWev3BqSTH9x.qqLCLoTfrKy2SdsjRGGjFNit lYJjLZy6sJRHvjgYahCevQzm2w.SlaHkS9d3rroHBr9QdnwKtefldcD.2dZQQJXaUU7Ov8T.MVo3 7i1rNv1x7PNOcNJJuDEmukh1pePLhey.8j5ei9etm7vwgN6RBAw-- X-Sonic-MF: Date: Sat, 01 Jan 2022 08:58:32 -0500 From: "Alex Xu (Hello71)" To: musl@lists.openwall.com References: <08c0476d-3ad5-85fe-f2bd-51bf8c21268a@m-labs.hk> In-Reply-To: MIME-Version: 1.0 Message-Id: <1641045086.i0hohehzro.none@localhost> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.19551 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Subject: Re: [musl] building statically linked DSOs with musl Excerpts from Joakim Sindholt's message of January 1, 2022 7:56 am: > clock_gettime(), which gettimeofday() uses internally now, wants to > check if linux provides a user space fast path through the > injected-into-every-process VDSO. > When the dynamic linker, in this case glibc's ld.so, loads your binary > it will do a bunch of internal setup in addition to symbol stitchup and > whatever else needs to be done. Here you've run into the first of many > brick walls. Musl will set up its own internal global libc structure > with a bunch of values during the initial dynamic loading phase; among > the members is libc.auxv, which is what __vdsosym will look through when > trying to find the VDSO. Since you never ran musl's dynamic linker (and > even if your host binary was musl-based, not the one that would have > initialized the libc.auxv baked in to your statically linked DSO) it > won't have set up this and a whole host of other things. >=20 > It's not just a question of "just run this setup code and it will work" > either, as a lot of libc functionality by necessity depends on exclusive > access and implementation details that can't cross the barrier you've > set up. >=20 > Best I can figure your only solution, if you want to ship your own > ecosystem, is to start another process and talk to it over a > socket/pipe. > I'm sure this wasn't a very helpful post. Maybe someone else on this > list has a solution that better fits your needs. >=20 > Joakim >=20 Yes, this is fundamentally impossible. You could avoid much of this=20 difficulty by attempting to statically link or otherwise forcibly bind=20 your library's dependencies to your alternative malloc; however, this=20 merely decreases the size of the issue rather than removing it. First,=20 malloc implementations (may) use a process-global resource: (s)brk. It=20 will cause havoc if multiple implementations attempt to simultaneously=20 manipulate it. Second, even if no more than one implementation uses=20 (s)brk, they will still have incompatible metadata. Consider the case=20 where your plugin allocates some memory with malloc, then passes the=20 pointer to Python which then frees it. Since an incompatible=20 implementation is processing it, it will most likely destroy the heap or=20 crash. In conclusion, without extremely careful preparation of the entire=20 program and all its DSOs, it is mandatory to use a single libc and=20 malloc implementation in all DSOs. Cheers, Alex.