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 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24254 invoked from network); 16 Oct 2023 14:26:13 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 16 Oct 2023 14:26:13 -0000 Received: (qmail 20265 invoked by uid 550); 16 Oct 2023 14:26:08 -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 20230 invoked from network); 16 Oct 2023 14:26:07 -0000 Date: Mon, 16 Oct 2023 10:26:04 -0400 From: Rich Felker To: Farid Zakaria Cc: musl@lists.openwall.com Message-ID: <20231016142603.GL4163@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Getting access to section data during dynlink.c On Sun, Oct 15, 2023 at 06:06:48PM -0700, Farid Zakaria wrote: > Hi! > > I'd like to read some section data during dynlink.c > Does anyone have any good suggestions on the best way to do so? > I believe most ELF files ask for the load to start from the start of the > ELF file. > > I see in dynlink.c the kernel sends AT_PHDR as an auxiliary vector -- > Should I try applying a fixed offset from it to get to the start of the > ehdr ? > > Any advice is appreciated. > > Please include me in the CC for the reply. > I can't recall if I've subscribed. Neither the Ehdrs nor sections are "loadable" parts of an executable ELF file. They may happen to be present in the mapped pages due to page granularity of mappings, but that doesn't mean they're guaranteed to be there; the Ehdrs are for the program loader's use, and the sections are for the use of linker (non-dynamic), debugger, etc. In musl we use Ehdrs in a couple places: the dynamic linker finds its own program headers via assuming they're mapped, but this is rather reasonable since we built it and it's either going to always-succeed or always-fail and get caught before deployment if that build-time assumption somehow isn't met. It's not contingent on properties of a program encountered at runtime. We also use Ehdrs when loading a program (invoking ldso as a command) or shared library, but in that case we are the loaded and have access to them via the file being loaded. Depending on what you want to do, and whether you just need to be compatible with your own binaries or arbitrary ones, it may suffice to do some sort of hack like rounding down from the program header address to the start of the page and hoping the Ehdrs live there. But it might make sense to look for other ways to do what you're trying to do, without needing to access non-runtime data structures. Rich