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.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 20896 invoked from network); 2 Jan 2022 21:41:22 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 2 Jan 2022 21:41:22 -0000 Received: (qmail 11557 invoked by uid 550); 2 Jan 2022 21:41:19 -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 11522 invoked from network); 2 Jan 2022 21:41:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1641159667; bh=znl6rUcKQdMDd1txJIryidft/BBWmQWa2/ZDt0x3a1Y=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=CxpAXg4WAZlu5+JJ7WO3KG3ptadOYWXrR3tOVvt6LdW3a8IqiCqr4zEh1tJSN0odL ORFQYHBK4WH9TofAmukstRpTh33a/bV5SODpMs2bXtyeyO1UmTx9qfyzeVFo6fuBeG RlUqQFttT4vgWC+kjzfjVtysdyIStwNRCG/xpMdo= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Sun, 2 Jan 2022 22:41:05 +0100 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20220102214105.GA2629@voyager> References: <08c0476d-3ad5-85fe-f2bd-51bf8c21268a@m-labs.hk> <1641045086.i0hohehzro.none@localhost> <54060b8f-2ff1-fa1c-abc7-ac4996858ffb@m-labs.hk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54060b8f-2ff1-fa1c-abc7-ac4996858ffb@m-labs.hk> User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:t5EMnK5MMzUqdKCfNjBiMtNKjfbuJhFRsMyhDrl09BFUsgHlGrg xPAudNHWl0BKyNTdPH77sjNzWysQCjhZj+Ml9rtjyBTm4Nqnad98T6SH1htHHH3/bEKgi1n zfuQqfBuhuldP4EvKXW2YoFYIy4Le5Etuo6/nZDYdiw+fQPqfQpKeVwuuNbs4waTyB4z+qW yJMevtyV9ih5WAfdiRGtA== X-UI-Out-Filterresults: notjunk:1;V03:K0:ePoWadtc7MM=:zE7bGvqPE4fwfi3EJ6+ZXI VSWYcUAcPQfiSFpoifY7MmvOgkL5QGPXPXl444wUCfCEeupLo3ZQlVCPCkqWXZpSIYydulQYs a9+GGmQ3U6GGrZVxL/UYR6PuFyDbQz2NUop/gR7pFK2eaj5x7yJp+/1c8kRhkzx5ls4baoYoe 4h8TFbfA/PSEOlWoaax9F8XhC7ONEWTlUw0nPNSVP6LI8+HdhIan0b/boucsWSyn+bXj10lIk rxtUnhzaUSS8RzzOjnOhfGeGUUJhLxuzzGCzs/2+990AmSrG5v57NUFsU5CAtYQ+XIpyFap6E JN164mmgWvg2L6KmEizkQFci0ksdTvuocbf7URAcMNZFCglyi5a4b2Rk7H+RSjblznKf7xAvy I2/asMVAwinrN6tUpvtv7JT+PHtZkGRUUmZoQ1E6z9F5fgvk3LawsROAoCzxU1/7Jpe5MC/Mz CK72mTLJ0YZgWqYIXU/PmeC50ys8n42PkWWvsjGqEzXS9T5GavV3kpCuSV5xljTPLJBe0VHSF aihamSaTrbcZWE66J4DHawuSFb2cEVIWJ/YlTS2I+n6cOev/M1LWqBQdHuUi4AXEGUaU5FF/6 /CYV34/rcYjZxYkEzU1Id/2xZHJam1nuKSw5BCVO2dANAWHiSlNvHD1HgvEonq2d9q2LXXfYD jffJo7OZFehB5SVSEa+qWZgQWQIYsiMaRK5jXyiOOm6DxlJHp7ILQU0JsPYOh+YoZK1XkS16e Em0jCDG/P63QeS5sOjJoE4pyByBPEYHb3t0MyFU54ruhdUfTibU+1BNfT6XCcDNjqT8LvN2uV lN/u2nRF/km7uq2JWnTydgC80JugQwHjptFETrty9uLgi++vpLJPzCYooicaU2ZsoB9rbwACh HuenoDhtSDhN11vtPmbUIBLr1NOVoV78HdRU4dO1TxoLnye+mV6Ay0qGcOCjT9ibd68fstNsZ SG0GPFHfmX+Lej0+miB0mtgDNk3GobAlhk12wTNyGSeUEyIGPDq4Gt/6grNrQqq7hCqbF39+7 F3Ln6ZSBpUmpf2JFxv7kyGyjkP/N+8G90tUYMyQ2AWKvcBh04Kh+lunJcU+RLFK+zmF0HsBjw sBR485xGPeJPGY= Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] building statically linked DSOs with musl On Sat, Jan 01, 2022 at 10:31:58PM +0800, Sebastien Bourdeauducq wrote: > On 1/1/22 21:58, Alex Xu (Hello71) wrote: > > First, > > malloc implementations (may) use a process-global resource: (s)brk. It > > will cause havoc if multiple implementations attempt to simultaneously > > manipulate it. Second, even if no more than one implementation uses > > (s)brk, they will still have incompatible metadata. > > Can't there be two different heaps in different memory regions? > There can be different heaps, but not different brk heaps. Basically, brk() manages a global variable generated by the kernel. You can work around that problem by installing a seccomp filter that makes brk() always fail, forcing the allocators to fall back to mmap(). However, your approach has numerous other problems, especially with the mismatch between glibc and musl. The thread pointer does not match up, and so no functions accessing the thread pointers will work. That includes functions that read the current thread pointer, so you cannot know in advance which those are. All the implementation-defined structures mismatch, so none of the locking functions work, and neither do the semaphore functions. The thread-management functions also will not work, and you are saying you have complex dependencies that might use those. No, the best you can probably do is put all the work into a separate program. Define some sort of IPC interface, and have the plugin merely serialize requests and read responses. Then your process can be as complicated as you want and use whatever libc you fancy. It can even use a custom malloc. And your plugin should be rather lean. HTH, Markus