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.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 9357 invoked from network); 16 Oct 2023 21:22:15 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 16 Oct 2023 21:22:15 -0000 Received: (qmail 24057 invoked by uid 550); 16 Oct 2023 21:22:12 -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 13914 invoked from network); 16 Oct 2023 21:09:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucsc.edu; s=ucsc-google-2018; t=1697490558; x=1698095358; darn=lists.openwall.com; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=cg7k+/6IfVo+tsZ+EN5BpKZT3Wb6oliXSmDkTiz2CmI=; b=XfSTnBBhHuX0t2l0kXX1opZGXr11ONfuxTev+ps4m1lUMOl/Afty7F3DgDSpNMaejt g+K/BNoE1qUO0eAZIcSH5Yis7lRkFBgzo7nwPP/8lt5pG1ei4G7RXCq4D4AyU3riepu0 fuYmZdN4R0T7enVjPwKg/VvcA8CEDR2TFHTN+UpXZcsVtdF7ca3KZh7AbgQeXg0W4cbr CmpXQEJmIYywe5PIkD2jbSbsmsFV+t1epRRD0MXOUe45g+5/OQWZxCPnX2XlNGJjL5zm XKblNFuvovd4gT0zeUPOa6KV4br3oWeTpgAHxsj39NMHT4GKnvMSnm9m6FUGi3lK3Kpi Tgyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697490558; x=1698095358; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=cg7k+/6IfVo+tsZ+EN5BpKZT3Wb6oliXSmDkTiz2CmI=; b=WTWuozdmBs087dj6Vx7zyOCBg250rWO0oTTyqlPEIYueDnZOtbm3IDkYf4f+IVRrJU Fj+tWLbhjzUUC2Y9c42QMyznxIY7t9AQrY6786NT6BQ/uQaHUlgyY92tM+4o95XEpWzc 64Odj6URdmaVDXgBzG3e3rKfWLRABsjI0eOTwpJfG8Ouqm10sQqBDZdWBHWJ3KqLeqgL gD7W/IjA1kJ1pDWX920ihjVE/MRj1S1M6/pIKvhqcuff/LkFEqV6n37PX70c6zRPbksn WL7L6Yz8U4kg7XST740tHr3hyQa8Monz4S9Nxx6mDbcdnSBBbGgIkGQxDVumJg0WAIL2 8PmQ== X-Gm-Message-State: AOJu0Yw9kDilYhN5hsy/OP5FcJNtMkoAlKw9oQQHEwv7CD46VlQaus8+ lQeSc6gKsADslQBxPsMxLpp3JNF2sY+ztLkChyGyxQ== X-Google-Smtp-Source: AGHT+IFhKUmV4YhuiSRqFc5qww618mOIAUXbhqm2HuQjKCU5zPiFXf2kFvUmlLMgymsIZtrokqFv+Wm45Z0dS9Jh8UA= X-Received: by 2002:a17:90a:2e85:b0:27d:2763:a13a with SMTP id r5-20020a17090a2e8500b0027d2763a13amr261102pjd.48.1697490558504; Mon, 16 Oct 2023 14:09:18 -0700 (PDT) MIME-Version: 1.0 References: <20231016142603.GL4163@brightrain.aerifal.cx> In-Reply-To: <20231016142603.GL4163@brightrain.aerifal.cx> From: Farid Zakaria Date: Mon, 16 Oct 2023 14:09:06 -0700 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Getting access to section data during dynlink.c Thanks for the advice. I'm now looking at the following two options (seeing if they work): 1. I see that an auxiliary vector is the FD or the name of the file given to dynlink. Can I mmap this file again in it's entirety and read the section I care abo= ut? 2. Try to create a segment that maps to the sections I care about such that they are loaded. (Try to apply some heuristic to then identify it) Early attempts at (1) have the mmap failing -- i need to debug further. On Mon, Oct 16, 2023 at 7:25=E2=80=AFAM Rich Felker wrote= : > > 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 th= e > > 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