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.3 required=5.0 tests=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 25739 invoked from network); 8 May 2022 13:55:00 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 8 May 2022 13:55:00 -0000 Received: (qmail 22040 invoked by uid 550); 8 May 2022 13:54:57 -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 22007 invoked from network); 8 May 2022 13:54:56 -0000 Date: Sun, 8 May 2022 09:54:44 -0400 From: Rich Felker To: Markus Wichmann Cc: musl@lists.openwall.com, Pablo Galindo Salgado Message-ID: <20220508135444.GD7074@brightrain.aerifal.cx> References: <20220508113910.GC7958@voyager> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220508113910.GC7958@voyager> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Why the entries in the dynamic section are not always relocated? On Sun, May 08, 2022 at 01:39:10PM +0200, Markus Wichmann wrote: > 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. That's basically it. musl does not do this mainly because it's not possible in general -- on some archs _DYNAMIC is in read-only memory -- and we generally avoid arch-specific behavior in the dynamic linker. The only part of _DYNAMIC we modify, on archs where it's allowed, is DT_DEBUG, because that's a (nasty, should be replaced) interface with debuggers to let them find things. > 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: It's not so much in the scope of dl_iterate_phdr, but in the runtime contents of ELF data structures. There are specs on *some* of that, but they are not among the list of standards musl purports to conform to (and for example some things like handling of RPATH/RUNPATH intentionally differ from legacy behaviors here). > > 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? Indeed, this is probably either an XY problem with a simple portable way to achieve whatever the underlying goal is, or a glorious hack that's making a lot more assumptions about implementation internals and not something you'd be able to rely on continuing to work in the future, even if you got it working. Rich