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 9391 invoked from network); 16 Oct 2023 21:22:25 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 16 Oct 2023 21:22:25 -0000 Received: (qmail 24460 invoked by uid 550); 16 Oct 2023 21:22:16 -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 19709 invoked from network); 16 Oct 2023 21:16:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucsc.edu; s=ucsc-google-2018; t=1697490994; x=1698095794; 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=c79ZJBiyw8oULmm/F+dJWAI9u2ia+IcK1/zpFDj6G7k=; b=k5zEbdD9Z0sj9dH0VhM/PKrpvCBu9glXLDbu0+wIoXIWX2LsZ8p5W0yG1CLV/CG5FA Ga7U3l4s/aE2DJ7QynSppiBQ93g97cSZ5yHp6mIUjAeqxiHLsq3RM+6Nuo2XzMqmU5yz IKQyT8TzKYVg5NdESYli+/nmFhRhZfYdItIYClZ0vXLzXPU3+YMG2LlI05OLC5f7WOOD ViNXWQaMHbhCSWQ9GL1GgafVAJ58U4hLK1weHErx8zh/k5tOwVmYLsMdVLhVgX6JdS8g QyoGkzMYtymmVQiNhA3A3YqzbhtnDrMTY0ZtqLjHET4jK0/08e3hR1ytSSraKd9d/sF5 zzVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697490994; x=1698095794; 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=c79ZJBiyw8oULmm/F+dJWAI9u2ia+IcK1/zpFDj6G7k=; b=OJNMAQ3mQOe0RHFZ9Iy/AGo1TWC+qNkb2B+EYWUq2cbnavM2wMK4sT5GiRe+or1k5T dyN7sV9s1WO/dUTneuMB7c1RXwowsPz4dbESHg0gi28E7eyvXdMB556qJB8WZRPpc4r2 mGzC8wY/nT1v9TD8SCgIQg66MQh9Tntvz8d0AjPBGwSTQc2VFhcgsvIaHaBG7WFfaFb4 gFUnxTQohwjZ/XqOgsVm0zW1SWuimrYteceU0ce9tU6/BdYR84/uvAu5awG7K7eRVS0y eIbdcC20p6pd8hOq8Q45pURlKni/N26nCCjPUOH6bWlmfHs/zM2tBlLiCulBR8vqpDFJ a0Uw== X-Gm-Message-State: AOJu0YwLQZF1OBaSxCnngFOKUZG769ZnSZ5Gp+7TNsZK31FIuxn4Wtf0 iF5/cy9zrFa0s/JFBigfCBLYcUhFMvlvD7TIBsene6KkY/P/gazJqvZl6Q== X-Google-Smtp-Source: AGHT+IFhp7XrGAGh0szHHkHSBis5peVluDknq/UdUslHtHA3c9/sL8CHCKPhNggic5Kxrk/Da6d/gRFGNNxM4S+W/Iw= X-Received: by 2002:a17:90b:4b:b0:27d:8fbd:be95 with SMTP id d11-20020a17090b004b00b0027d8fbdbe95mr364341pjt.28.1697490994627; Mon, 16 Oct 2023 14:16:34 -0700 (PDT) MIME-Version: 1.0 References: <20231016142603.GL4163@brightrain.aerifal.cx> In-Reply-To: From: Farid Zakaria Date: Mon, 16 Oct 2023 14:16:23 -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 Okay -- the following works (see below). At first I was trying with AT_EXECFD but looks like it's not set for ELF -- instead I used the app.name variable. ``` 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, fd, 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, ".watever")= ; if (section_header =3D=3D NULL) { dprintf(2, "Cannot find .sqlelf section\n"); _exit(1); } ``` On Mon, Oct 16, 2023 at 2:09=E2=80=AFPM Farid Zakaria w= rote: > > 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 a= bout? > > 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 wro= te: > > > > 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 t= he > > > 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