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,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 6993 invoked from network); 8 May 2022 11:39:27 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 8 May 2022 11:39:27 -0000 Received: (qmail 20359 invoked by uid 550); 8 May 2022 11:39:24 -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 20324 invoked from network); 8 May 2022 11:39:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1652009952; bh=DuXhvTg+8xhH71jiHX1Ue8RdoLShtIEQKkzypFPchSw=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=CRedPJYZv5f1ul6Fw6mSQDNVxDbhA3EzKpU2kb1eMCd0NXuBH5kEsp26uBN/k/EEq sdwB+j21vpOClgbnr/tsD6GDKso62Xxb3slpGClYaNZxw2Yu1WKIQl0tnQuyUzLeTH JN6IT7VOWUFDNllVb+VRjIhS3ZGZVEA8AahyfG3A= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Sun, 8 May 2022 13:39:10 +0200 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20220508113910.GC7958@voyager> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:O0mD8lmlYTO14e8e9XrOmRcai7hjIZuNzrj81lfCDIKouXRFH5m BzaezqG1G4wZgnnJTV8rUpWMRu9GOFWOqenRVKkLFzCuJNNFd3c5UN7TbcugUj2zLcilmZj teSFxS3q+MphbspkXUi7dL19gS8+yMDv0lLco3vopypoPtSHt+YLzGqEZt8i9T+DHB0LETq GU8Hser4R8xaM6QzFoZ2Q== X-UI-Out-Filterresults: notjunk:1;V03:K0:9R0cuOP/uOY=:iNxsmn3nv3sRgpOX8spXxa uK4ss8skToVxPASjiNra/di+wVQXaGbpf4h2g+gbvifUSNTS3DO5sYTdRnyIk/TeDZPI5nk/K OPlYELrnzAwX/xO19lYy4+m7LHm15k8rlrLEdBeVIKz2JG730ZBxJFjZcpFP+6JDUsGV74MO0 DxiFerhDcwI7ZT1ncTf95OxGwV/mJLgc26Yzx915k2eaOsZmTie4Dgmizz8O0Sz0OndurBYq5 x7jThipVnYXMmcJbdBgnhg+yulmwIGDYVhYyvyJ2tLGVaGSJP5HYO4ubbMquTECXcLpIK/EPa ZwwbOh+COc3Np8vCS0LbGkji1JvDPT01jGhywOzFgBT3J2PSioqakdoXyk3r4T5G4YVxSm36W 8AEEh4rGJgRXrAPKmSxSWXp4xWLijVabkzk0xURVpokIZpMote6QAK8QoP6rrqsQqnSo+gZ3v dxn2b2gRDcBvOmj3vi4J869E66LBPI75zeGnF+ZbG0dVzDSWszslyryB1ZxY+82m+WZfrt2eE E+nSknk6i/eVWqZSA9al+qmmpj4fKuP1rLTdoPph0dFZZB0XZPrQv0uz84y4AqZy1SOMNtN+k lepoyuIx51yFIOJXwIns9REMYX54hV+Azao71Mn79taj08RKhCXnUhL2arGX/gf1HMY8KuAjm bq7ADhr/k4M/lzZE00RtNdPoP/Ctf4Yj9VcSZxIHduqOGwG3UGrWhKc30zUQzl0mB26VXBJ1e IzU1ZH5n4kXUm7kcS/BxMVoGZSoNAoC7JaHZe1bzoDWd09KshbU0cGez4H5vyYJ51qbPJWgQm +1tkqQ1/jiU4y7hzn+ycE8q/WEU+JWb85iKDyaGirmLZx3Ukf0RQKZaSE785WWsZ2at7BKqM6 d1eZ+ommuGTobRsWAuMVCLAxdykKY4ThRoM6f72T5HotxF2CGJC9amvLuERBHNEsyKkV9xbLj 7S+B96teMKYeI1+d/Z29wcFIXGhpPVikI7ejNM5a+MCL0N9N24RnIawYbmTnnQK3ty0v7Z5jB vNP7z9W4XSSh2b/lkMxiBS9waRH4aLu7SO6Ur2glaBLaLu2pvYtV+9aPz/HVenKtSStCUnkLR UM5YSzQ1cl2NrM= Subject: Re: [musl] Why the entries in the dynamic section are not always relocated? On Sun, May 08, 2022 at 08:48:29AM +0100, Pablo Galindo Salgado wrote: > Why is this happening? The easy question first: This is happening because glibc finds some value in writing the actual addresses into the dynamic section, and musl does not. All of the addresses given in the dynamic section must necessarily be offsets into the library itself (rather, the run-time map of the library), so anyone who knows the base address of the library can interpret these values, anyway. See, you are accessing an implementation detail here. I am not aware of any documentation of dl_iterate_phdr() which says whether the dynamic section is relocated or not. Which leads directly to: > How can one programmatically know when the linker is > going to place here offsets or full > relocated addresses? In general, you cannot. You could reconstruct the length of the library mapping from the LOAD headers, then heuristically assume that any value below that is an offset, and any value above it probably a pointer. Doesn't help you far, though, since you also need the base address. Though I suppose you could assume that the start of the page the PHDRs start on is likely the base of the library mapping. Also, the heuristic will fail for libraries mapped to a low address. In theory, all address space after the zero page is fair game, right? But libraries can take more space than that. And God help you if you ever run into an FDPIC architecture. It appears to me that whatever you are trying to do is not possible portibly on Linux at this time. Could you fill us in? Ciao, Markus