From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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 autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id 012900a1 for ; Wed, 29 Jan 2020 19:20:01 +0000 (UTC) Received: (qmail 19913 invoked by uid 550); 29 Jan 2020 19:19:59 -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 19895 invoked from network); 29 Jan 2020 19:19:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1580325587; bh=S+rchr7gw89ZFAYm69vf/3COgLWq8kz4khNtSk/Bd/Q=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=JEduYz5+l35jxQR/fug6yeEjvtG8OWMI2wPXL8UwvnZ0JXFQWktHBIn90hD/maKng jpH9FoPu7pskaONE7UQ5cCRBScz9P4Hnca8sXiYHpKZNsgtENwwMEkNM30ZlCsgz7G Ca8n9fJJDy3apu4ap0R+NzslsAnOMekU5V7HgVmE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Wed, 29 Jan 2020 20:19:46 +0100 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20200129191946.GI2020@voyager> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:o3UNMz3XcICjZaRV0i/sQP3DC2tUiBjN6E0QkFijjnIb8+qfS6f UUIzGRQ8muuyMtCpETK+Fb8/wDu6WsdFF3ZpW5UKiB+feisY9EgP/thQ1ulBUx64VcmeAW/ D2NfKTyFPCVth2lsdHih8hhFRsxxlBsx1OqGeZ6AcrOlusyGeN8FdLw/RA1IFvyFIhulOsS ApRJqHiJDvNnaynr8cEcA== X-UI-Out-Filterresults: notjunk:1;V03:K0:fywU6ml+UYY=:/I3iJVE0xh/QcHz2TLLScj l7zlOM0VW6zuMQsqgfB10/apZdwukCv37eyjKHzAY5ZZ5k8Zyu5wdW8OqhH3YeiTdRVvzx3qV vCedIEgxMQWJB4yyXU6iV1tJHN4egxRHuVvHI3EZacKGE8s+sycO/62YCuXCW+Ua5/++WPlvQ wrAgYqtXUlHnbf6Jng6lyUsr4oekpj9XNs/14bj0NhYwl14qsW4xczheW41xwe5EeD++nGery joQQAiJ6OnfCmaHK8d/rg2oLVjGbxEoWiqPFZGBuQFrYpe9yGeUDNNiiPdu0y1ojwmw4ovHpX Ws+xBYeRJSGpLPU1W1i8kZRGH0tycbhb3Kf9AVKD5JR5P37thgm6Sm0QGnJcJNHzG6+PH34B2 jwEEbpNbcYne4hPHmN9D+41pqgBqdwhHbbEVJB2pGVcJhaDTpdMtPoDXg42CqMpe7ykev52NJ u7PbLV3d7gFQTrFRmgJbfQi+dmKwL6LyChttUQkXGY4K9mZ1bbLvUfS8+XDYGHC6K6fjkzdgm K4kGN9p2SQHtPKGZmnyMTd20qz+3ld5hZKzzD61KarcUVcoHUWXYsA4spoC0JIFFUdWRk/378 VqwNSp5g6wI3wmW0m3+7GYlSh/VWszqTP04E589MtQTz1xIULcVCJUciAo7TEuAuuPeDNy2s9 mJNF8GVzLmgOZcb9TPA4XapXXQFLJ8KKR8jMFV7JSR3PFs0q/Ozw7GEOlYVQG0ac4uBBDYUDw lpIM+81U85xX39nDqhrcYAkQ5HR9yZepxExsD1WnldYh1LuncUQyqyUeUy7wazxbG5ktAKWGn SjR4CukhN+lHWQG6ZVBX3fEFnkhCrgia9Ii5+3fAre00woDATV2rvRp9XyC7pw2P9c4bBq92Y 9BZhjW07OZxOM3IVmiyY6KG+ff2MvnyccB5W1N+fxS5i2cQGlw5/GL3Bov9g9qeoeQWyjA9fp S5TA7JGSP4QhxRBPEbxeuh4nVibf66orotJcgcyRgRoI6D3PWXU9J3+3H03jWcBXieWykpI/j ervKiFD1b3cyJ56GXxVMgIDIE7HRZHp9by/LvS58exYNFZp/AOB0Afiyt+4cLte7eSNNTTswB LgxLKHGn+PYzmp4szouFFYvSrNyODPdQV/eSQDGEBxgDGGWy192pEUa9nOtg7HALIHfkkwHYM 5MAbdJewsdWSs2BjJgvkbfdKnfxC3jLEwQMxBL6hIuuYnW14/+UIAs49QFKclYvci84SMsYRA sH8gfX5FK/DZbpRbm Subject: Re: [musl] Static linking is broken after creation of DT_TEXTREL segment On Wed, Jan 29, 2020 at 09:41:46PM +0300, =D0=90=D0=BD=D0=B4=D1=80=D0=B5= =D0=B9 =D0=90=D0=BB=D0=B0=D0=B4=D1=8C=D0=B5=D0=B2 wrote: > gcc main.c /usr/lib/libgmp.a -o main && ./main Ooh boy, why would you do this? When there's a perfectly good -lgmp just waiting for you. > warning: creating a DT_TEXTREL in object The warning is justified, you usually do not want to do this. With a TEXTREL, the code has to be mapped as writable, so now programming errors and exploits can change the executable code. > We can see that "laddr" provided pointer to "dso->base + rel[0]", than > switch tried to override it's value and segfault appeared. Pointer is > wrong, most likely readonly. > Pointer is correct, but memory should have been mapped writable. More on this in a bit. > You can replace "gcc" with "clang" and everything will be the same. Upda= ted > binutils to most recent version 2.33.1 and rebuilt toolchain - nothing > changed. Pointer is still invalid and SEGV_ACCERR appears. > Of course. The issue is a relocation inside a read-only segment. Binutils and compiler are not malfunctioning. > So I think that bug is inside musl itself. Glibc container is the same > situation works fine. I see no way to create a workaround for this issue= . Well, the remedy is obvious: Get rid of the TEXTREL. It is usually caused by bad assembly source code, and fixable with only minor knowledge of the details. Consult the search engine of your least distrust for more information on this. Regarding the actual problem though, the problem here is that DT_TEXTREL is handled only in map_library(), so it is not handled for kernel mapped DSOs. Which isn't a problem for libc or the VDSO, but the app itself might be TEXTREL (and is, in this case), and that isn't handled. How, though? Iterate over the apps PHDRs and remove write protection from all RO segments? And one more question: Since musl resolves all relocations immediately, couldn't we write-protect TEXTREL modules after relocating them? Provided no unresolved relocations remain, of course. Ciao, Markus