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 24485 invoked from network); 17 Oct 2023 03:40:05 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 17 Oct 2023 03:40:05 -0000 Received: (qmail 9889 invoked by uid 550); 17 Oct 2023 03:40:02 -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 9857 invoked from network); 17 Oct 2023 03:40:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucsc.edu; s=ucsc-google-2018; t=1697513989; x=1698118789; 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=pOdBX/olURJK+mYWhXnwlTJ3NZJ04yFC/kTlf7we7fM=; b=K12MbWdi+OelRnmme/Sst1eY7OCu7vdIx18e7nbYSptsaKBszl44Pp2NDqFA34I095 g8SfaOIBoDHH4lGCqPucfeGh7+GlZFcjioUv0JtPm5Wl0YCmHBpEN8HAJuFAITt1man1 iN9sMMxMD3p7pw+xadtMxt7jbchOARGIJUpOdlymI0EMMhbsUY2hUEQ6K2XXM7ipiFLm k/u7lplnyfO/tvDZgd9PthUXj7jgl6w55SSwoji4XfDtckhkc/d5TnQ6PnfgD1k7QMzm MbVilutahyzJz7HaBhFHhPb9tdtPW1IZ9yYxvwmJL6Kc/aMnrWP1EB510ziBYIb0B/qr c1rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697513989; x=1698118789; 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=pOdBX/olURJK+mYWhXnwlTJ3NZJ04yFC/kTlf7we7fM=; b=YcricVjgNSkR7kLwnHgsNL6F03ituNe2niyfz8jAeAqgohOd7+YxPlW06ved7k6Lih TXrKhLQxYYqnyNAYcTdS3KueQ0ZxMtBbEoRp2AJCfJCIOWfChJqFc0Xg7MGKYj5uQiKK 0MwnEC/NIQ0FvT6AsykruvVOj2842KQDgldsB9t6zz2YLuZVKuD+6ajN/pL2shRednwq x1sJXHFUuzC5I3+8rgV9vs7iMEkxoOdjtSzbnd/zObAcyr9TbRpDe+d9ZDPvv9cBHR48 s4wR3dOyNnwr2wpx8zky2jvvEfkybu+6TSFB8409QD5YAysASIBzqiyiNacy715i62ac 6gqA== X-Gm-Message-State: AOJu0YyVzeq6D7/l+JeJNLR57C+tDL7Nz8XSKb2LV3he62JzE2uwEzUr U6jr88NNYcLjpfkI+awiprWR+OIKngwbAwJZjtX40A== X-Google-Smtp-Source: AGHT+IFqlSk8XFwIGlKr9lbIcsG46M+wKltC94CmRRDSPZkk7d7zwwFI6KNUGJyMajntO1hOlDjaguahAx/msMtf0Gk= X-Received: by 2002:a0d:df51:0:b0:5a7:d8f0:a30a with SMTP id i78-20020a0ddf51000000b005a7d8f0a30amr1086961ywe.28.1697513989036; Mon, 16 Oct 2023 20:39:49 -0700 (PDT) MIME-Version: 1.0 References: <20231016142603.GL4163@brightrain.aerifal.cx> <20231016215307.GE1427497@port70.net> <20231016220410.GM4163@brightrain.aerifal.cx> In-Reply-To: <20231016220410.GM4163@brightrain.aerifal.cx> From: Farid Zakaria Date: Mon, 16 Oct 2023 20:39:38 -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 For those reading the list, I ended up just opening the file with the 'app.name' and then mmap it. ``` int fd =3D open(app.name, O_RDONLY); if (fd < 0) { dprintf(2, "failed to open"); _exit(1); } struct stat st; fstat(fd, &st); const ElfW(Ehdr)* ehdr =3D mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, f= d, 0); if (ehdr =3D=3D MAP_FAILED) { dprintf(2, "failed to mmap"); _exit(1); } if (!ehdr || memcmp(ehdr->e_ident, ELFMAG, SELFMAG) !=3D 0) { dprintf(2, "Not a valid elf file\n"); _exit(1); } const ElfW(Shdr)* section_header =3D find_section_by_name(ehdr, ".some-sect= ion"); if (section_header =3D=3D NULL) { dprintf(2, "Cannot find .sqlelf section\n"); _exit(1); } ``` On Mon, Oct 16, 2023 at 3:04=E2=80=AFPM Rich Felker wrote= : > > 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 o= f 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 guarantee= d > > > 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 t= o > > > 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 t= o > > > 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 =3D (void *)__ehdr_start; > > printf("ehdr %p\n", ehdr); > > Elf64_Phdr *phdr =3D (void *)(__ehdr_start + ehdr->e_phof= f); > > printf("phdr %p\n", phdr); > > } else > > printf("__ehdr_start is undefined\n"); > > > > // to compare against the actual mappings > > char buf[9999]; > > FILE *f =3D fopen("/proc/self/maps","r"); > > size_t n =3D 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 assum= es > > ehdr is not at exact 0 address, which is guaranteed by usual linux setu= ps) > > Interesting -- perhaps we should find a way to use this in ldso to > find its own ehdr. > > Rich