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 e1c2b339 for ; Thu, 30 Jan 2020 17:03:04 +0000 (UTC) Received: (qmail 5832 invoked by uid 550); 30 Jan 2020 17:03:02 -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 5808 invoked from network); 30 Jan 2020 17:03:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1580403770; bh=qKc8aB+LbJcx6mopcYjGS0zcb4IwvYJMP3QCALHDnkA=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=jE/UsJ3DkYZYoAatCkjBSbDPbFlhYwmSOOA6uE7U+5PWmOgZMt6RHnfskU1ljGNuo JK9glK5/1rY7lzn0sGnvZwd7eqr2BhkL2pZ0i45xlfa4ELxmcvdeX0gqwXHNHe23K2 Wa6kr8bOl42Z3UuEx59Zx8ctzB7KEhZvzSMtomVA= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Thu, 30 Jan 2020 18:02:49 +0100 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20200130170249.GK2020@voyager> References: <20200129191946.GI2020@voyager> 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:cvQ7oepqE3b0jDtLmSh2jpf0iaBWCtaOaFTIUKdb9NeaomwVJeY 8ErRb+e5sQ/V43yVmgcCS1v7RKY48Eo/Es1NqGecTcs7XZGUr4akTpTnmPFsXX9GSYy3po2 /m4raow0z3d5uf4lhmWyWSjC9WKK+APT3rTfkd80bfcYKsqDGp9aOkpcMVBvFmi/ahdUDzO 1OBTxDozt5OS/CXY4ur+Q== X-UI-Out-Filterresults: notjunk:1;V03:K0:Iqp/KwHDcG8=:5odXegH9hHC+3/iP4qm5nu 66YAlwzzJVouFZYTgJyyiT5fQ/tiMhxjLlJj143IGDnHIOjByfM84rcaEUF+uklc3rOoag71N Lgsm+Ly6Cyjs9/dNcdu41ZpNcr4yj7TxKmKQ2ztvuqMyDZvTGO8Kkkw0Tp8TLvuK4NTskm6UE loKCaUHrG+dji5tGRwyD8/vArHGu1pXEsJfdWnF0zMH6ETyI95F3kXOhTNcb/dW56gu81i2bE UAnZvvJ/9x70Ne+HX+aOrhC2O0fAMw3MfSlhayMmEGGauEVCqz55uFpNWKpO0s2992z2twoXK WdjU1ixfThf4FqeHw935XHwBNhENdKgHwkikATmPkcBbOol641mRckqIP25K8JIeQ8ZEL3vex TZehlv9ddqzFrUYwm2bkWWyVR+dVi31YK8P8KoaShdKD21hzeASqhYDPrZK9d6aaPzZ4aXyxu BBD39cIOjRfxy8UVKMzFUD6MAzV68A+CzrD79K/GYg8S/W2aWoVjfF3etOIqkna2OIfxCgQnU SGHZmlTBq0DTQWOOHYTAj3mNv7i18CQuIkGOAR4YE+jpdoLKvS6kTstI5jOtCYzvDvNds2l1H a/i37dCRNHvwVaP9IUoj6wFFketN6Jk3yK5DicuHfg7Nnes0zUFs+InUkXYdrde/e+jHHq0CD 9Ol4Vmyqli1Eiqe9CcpbBwehqZT4lVlPaExhcTNUWMPfwzbs+R60hIONxROIdhBmOmzlvE2Ae bzaRbQMa8cj7eY8PVaL4lPxkrj+1sOK4dl1v5LxiDw5GewpHI9lg8f5pY3I8anMczG6xTDEgd 8dKRYQ7lXQjbQJhOVtF1djzXjZGyQwjVda7ERp74UR5306TPIwYhs/xHH8zfm9QllR9s3ja4L ZnTZ5YiWE9GWZVk7BAx8DZypkSwGBl35fXugsN95O5VdTyybIoXUVJX19t+0M/VV6VpVLYikX 0+e5HEQGa8Fq1U/599fr9ZQKXHVAvPOE6Qu/lBiDxejccipBq93sVjz84EhwpWX1NUZKA8qD0 Y5btJRL4qoVzAfVgcIGsw8VI6xK1lsywwEwx9r6CZOZa44ip45qDPfmyz17bEWh8g8omHz0zq V1dcYF4oonMN+WisuO4tJ8J6PKAWD14WcQZqXijYZ5a56XngLoai8vxQfltt6vggHYACvlgxJ O9S1HX0NSfXTleY4V0NGLnCtDJwKpLdKPKhuwym5S7uOcnjEzfSO1FVnBqEVmxcGM2G6y460J tKefKrluR4G9xs/B5 Subject: Re: [musl] Static linking is broken after creation of DT_TEXTREL segment On Wed, Jan 29, 2020 at 11:08: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: > > Ooh boy, why would you do this? When there's a perfectly good -lgmp ju= st > waiting for you. > > Usage of "/usr/lib/libgmp.a" directly is not forbidden by any toolchain = or > build system. Moreover it is recommended by cmake. You can google for > "target_link_libraries( site:github.com" and found millions of software > that uses something like: > > find_library(EXTERNAL_LIB) > target_link_libraries(something ${EXTERNAL_LIB_FOUND}) > Doesn't that search for the library in the correct mode? I thought cmake was that smart... > > 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 error= s > and exploits can change the executable code. > > This is warning from ld, not from musl. Segfault is not an acceptable > message from libc. Libc should not try to write into readonly pointer. > > > Well, the remedy is obvious: Get rid of the TEXTREL. > > Yes, I've found a workaround: "USE=3D'-asm' emerge -v1 gmp", assembly is > broken, will report it to gmp upstream. But this is not a fix for the is= sue. > There are several ways to achieve this. Getting rid of the assembly is one such way. In another answer you also advocated for --with-pic. My solution would probably have been to patch the code to never emit text relocations in the first place, which is achieved the same way in the end. The issue of musl not supporting textrels in the application itself remains, though. > > Iterate over the apps PHDRs and remove write protection from all RO > segments? > > So libc knows that file is mapped as readonly and should not try to writ= e > into readonly pointers. Almost all relocations point to writable memory. For obvious reasons. So musl doesn't check this. The issue is more complicated, because the app can have an unbounded number of PT_LOAD segments with the PF_W flag absent. So checking the relocations would require the dynlinker to first iterate over all PHDRs to check for the unlikely case that textrels are present. Only because they might be. > Libc can do the following: > > 1. Ignore impossible relocations. > 2. Add a warning to stderr and still ignore impossible relocations. > 3. do abort, user will receive SIGABRT and understand that he uses libc = in > a wrong way. > > Segfault is not an acceptable answer. > Have I got news for you. Unlike glibc, musl does not indicate irrecoverable state with a litany into stderr, but usually by calling a_crash(), which will terminate the process by executing an illegal instruction. This typically results in SIGILL being delivered, but on some archs it is still a segfault. Also, there is at least one place in the dynlinker where, as I recall, mmap() is being called directly, but rather than check for errors in the return value, the value is just used, because all error returns cause segfaults. And then there was the case of PowerPC's original ABI, now called the BSS-PLT ABI, which expects the dynlinker to fill out the PLT at runtime, which musl doesn't do. Trying to run a BSS-PLT binary with musl will therefore also very quickly segfault. musl doesn't fill out the PLT, because the ABI is old, a replacement has been in place since at least 2003, and PowerPC would be the only arch to need something like this. Anyway, option 1 would leave the relocations unprocessed, typically leading to invalid code references down the line, and therefore another segfault. Option 2 is the same but wordier. Option 3 has a chance to be subverted (user could block or ignore SIGABRT before executing the main binary. With SIGSEGV or SIGILL, the user can block or ignore those, but then the kernel will just kill the process outright if those conditions arrise). Options 1 and 2 also have the undesirable effect of possibly only crashing sometimes, not all the time. See the recent cuserid() thread about why that is a problem. And the issue you have with musl, not gmp, still remains: TEXTREL in the application remains unsupported. Ciao, Markus