From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 1ADB921BD7 for ; Sun, 21 Jan 2024 16:46:30 +0100 (CET) Received: (qmail 26582 invoked by uid 550); 21 Jan 2024 15:44:27 -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 26547 invoked from network); 21 Jan 2024 15:44:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1705851977; x=1706456777; i=nullplan@gmx.net; bh=FuvRoD2ycDXqltnpPkzF54GRt/ftuR9cDZ+Z8V+DjhQ=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:References: In-Reply-To; b=ni/hOsdIrFlbvoZHJF36u3+8P64MCPez/ExdW2bJF4Dc9PA0vxVKmXeUDC2dephC tPdn8+xIYvDrnpr/kGLtJYwYQrW2Mwh7VXWJgBVATDIdnHpNs/nvZ3u17dEO/6hui srZ6krhPlSbmgCbdB/YudnSEZKkUvyXo9SD0y0YWswIAeqwFMQFbeWO27aKs2bEdb Qn7bsiUPaOJkFrmHypBtPubTUhCNZL1CleyOqbXgshcC0lcvFynTS81hY3Gye+Fpw ULoyWMWC21GaG58xkZ92HI8CjZz3Thq7lvUsdUFxYo7e3jUx0iwba0vvKwcCnsCSR M60eRSYyDrV8Ebr/fA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Sun, 21 Jan 2024 16:46:15 +0100 From: Markus Wichmann To: musl@lists.openwall.com Cc: 847567161 <847567161@qq.com> Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: X-Provags-ID: V03:K1:ZbKPdtddjEVaIlmll2J3BMH89c1WUfNMS4QsOFLV4M+JMDpG3aG I4UHUux4WzqHCBCcW2nBMXkKa1MauZVUXkaZITo/d5z4IiIfIK6Vx7CCZwtG5DkgWUS1mbN MPIllrM4rBy/Q2o1goiZ5eR+qkRY60PO7H2IqR8pZnt+3ZJg46VQq8faEnv0R4ISex6ms5G trtzM4M0dxq1XLQ1nfleQ== UI-OutboundReport: notjunk:1;M01:P0:o0f8Yi3F09o=;t6oyRIuRQ3HCk8uPFjpebDSB5Am Oj33IMb8W7/wkca8a6vQeh5jFGr2f18x9qnwG/59JbxPjWkvxIaJ7Fv153/1u1fneD6XFGMVH ZqkBQ7Y1CNO1Z0kkXW5U6455bSsGRCxaYPxReJcQIoMUG1W71wQHG9tIxz7JB7fu7da4yiznW D0l6o/Ay90t08MfJkkrtUnDHN9s50J0NcDZTBgNqR/y2jZPMNwfn0ows/nfoMKlBQZenMwAk3 cqvGyebID7KXuVe/1887dWuCo6F49eLewfOgop0eEmXFGNHqvXMEn2Z6CdCpnM8ha7/GITzCY uRuPy33COLvT/YJWcHACkUiWE8FOSNR2bLzXE0VrnDGDXiJ/E0K9bD64Upq2Ga9Yj8POUqXAE jgdaS+S7QOyeTdM8b3C13GS6MX8Q8AvKOiTIE7np8FA4chP371AkOUXgeb3wtCu/607qz432m YKg+9nx711JyXi5wgjHBNF9oXS9t25QqflUs02zyhbPLLnrwarO18uFSzCfrMzmMCBbGejI/n MGVdDEgbS5/twWBN+frfC7pTRR5tjFff+N70s+7yn/R6gYQmxoBG3rOmT7vLyq/atWigHAsY2 sN8Qxd9FKi8i4pJGQ+U8CM7dzgY5HBM6lNyRAOsC4IvDI0kjjZhboXPthtb0n6ivI+WswbuPH Gs4aFgMsckLvED5FETWDICGRjL6oxASW5oF7j+riLM/Mk+SAL/QgsnIxsuT1ntdfS2wAXbQZk 9D0PVF7XOQmGUAL/d19Zv65SnfHejpVekW5aKhB/qzrc7dMkwNNDfudAWfcSn4w7sXtgsiQsT og49v2vmwtCNpVM/5hNC2nUZL2k4XXd2MDDqVba8nTT72Hl0pbS/MTYynQhDDFgu6b9/la34L XJPfL0q6NUDKTb5LcxrJxKxuaQIrLvkJdtO3DIR4GAcZfJbVgl+/ooeLgpYikPNCTQs3m4qRu cmIpSw== Subject: Re: [musl] =?utf-8?B?44CQTGlua2Vy44CRRG9l?= =?utf-8?Q?s?= MUSL support using TLS for both libc and app dependencies? Am Sun, Jan 21, 2024 at 04:56:40PM +0800 schrieb 847567161: > 1=E3=80=81About builtin_tls >   Q1: What if the size of the tls used by libc is larger than the b= uiltin size? >       https://github.com/bminor/musl/blob/master/ldso/dyn= link.c#L1785 > What's with these HTML entities in the plain text? Your email client is misconfigured. As to the question: Libc itself cannot use TLS. It could in the static linking case (when the TLS just gets rolled into the same section as the application TLS), but not in the dynamic one. The dynlinker currently does not set up TLS in libc correctly. Not entirely familiar with the list of things that would be needed to allow libc to have TLS, but it is likely to be nontrivial. I already foresee an order-of-operations problem. See, the dynlinker on startup currently works like this: Stage 1: Process libc relative relocations Stage 2a: Process libc symbolic relocations Stage 2b: Load initial thread pointer Stage 3: Load dependencies, process all of the relocations. With TLS in libc, stage 2a would already encounter relocations referencing the TLS which gets allocated in stage 3 at the earliest, because that's when the allocator becomes available. A gordian knot. The line you've marked merely sets up a dummy thread-pointer. It will be overwritten in line 2034 if the actual initial TLS allocation is too large. That would also be the answer to your question: If the TLS is too large for builtin_tls, it gets allocated (which happens in line 2017). builtin_tls is merely an optimization to ensure small TLS sections don't need an allocation that can fail. This can also be understood as a quality improvement measure since this way, most applications cannot randomly on startup for TLS allocation reasons when the free memory runs low. Whatever good that does in an environment where the kernel gets to arbitrarily kill any process it wants to. > >   Q2: I haven=E2=80=99t seen any processing of the tls segment of l= dso, so how does __copy_tls take effect at this time=EF=BC=8C where was&nb= sp; libc.tls_head be modified before this time? >       https://github.com/bminor/musl/blob/master/src/env/= __init_tls.c#L64 > See above. ldso and libc are the same in musl, and libc cannot have TLS at this time. > >   Q3: Is it possible to init main thread tls by calling malloc acco= rding to the tls size of libc at this time? > Main thread TLS is allocated with malloc (well, calloc) in dynlink.c, line 2017. That is the entire TLS size, no matter how many TLS modules there are. For static linking, main thread TLS is allocated with mmap in static_init_tls(). In that case there is at most 1 TLS module. > > 2=E3=80=81About libc and other so use tls at the same time > I didn=E2=80=99t see musl modify tls_offset when ldso uses tls, so when= another so uses tls later, their tls offsets will conflict. I will not repeat myself again. Ciao, Markus