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 11591 invoked from network); 16 Oct 2023 22:04:22 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 16 Oct 2023 22:04:22 -0000 Received: (qmail 32412 invoked by uid 550); 16 Oct 2023 22:04:19 -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 32367 invoked from network); 16 Oct 2023 22:04:18 -0000 Date: Mon, 16 Oct 2023 18:04:11 -0400 From: Rich Felker To: Farid Zakaria , musl@lists.openwall.com Message-ID: <20231016220410.GM4163@brightrain.aerifal.cx> References: <20231016142603.GL4163@brightrain.aerifal.cx> <20231016215307.GE1427497@port70.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231016215307.GE1427497@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Getting access to section data during dynlink.c On Mon, Oct 16, 2023 at 11:53:07PM +0200, Szabolcs Nagy wrote: > * Rich Felker [2023-10-16 10:26:04 -0400]: > > 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. > > note that (not too old) bfd ld and lld defines a hidden linker symbol > __ehdr_start that at runtime resolves to where the ehdr is. > > example: > > #include > #include > > __attribute__((visibility("hidden"), weak)) extern char __ehdr_start[]; > > int main() > { > if (__ehdr_start) { > Elf64_Ehdr *ehdr = (void *)__ehdr_start; > printf("ehdr %p\n", ehdr); > Elf64_Phdr *phdr = (void *)(__ehdr_start + ehdr->e_phoff); > printf("phdr %p\n", phdr); > } else > printf("__ehdr_start is undefined\n"); > > // to compare against the actual mappings > char buf[9999]; > FILE *f = fopen("/proc/self/maps","r"); > size_t n = fread(buf, 1, sizeof buf, f); > fwrite(buf, 1, n, stdout); > } > > this should work for 64bit elf exe if ehdr is mapped into memory. > > if you want link time error on an old linker instead of 0 __ehdr_start, > then just drop "weak" and the runtime check. (the code as written assumes > ehdr is not at exact 0 address, which is guaranteed by usual linux setups) Interesting -- perhaps we should find a way to use this in ldso to find its own ehdr. Rich