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 27037 invoked from network); 17 Oct 2023 17:38:26 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 17 Oct 2023 17:38:26 -0000 Received: (qmail 25849 invoked by uid 550); 17 Oct 2023 17:38:22 -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 25810 invoked from network); 17 Oct 2023 17:38:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucsc.edu; s=ucsc-google-2018; t=1697564289; x=1698169089; darn=lists.openwall.com; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=RZKS+tltAUjlfNVIiIJUhREBe4jbMUqPheQI19jdGnw=; b=bqNG+8LoWpzSpm9BJyrE7AkYuK/PyiuWGWXiHQ9zNGqg+v2pUjz9u8fnfWE/pre8GG F7z1DHxuAszjOiERwtav2EXpCm2/hcP8mj65UJNiiyFTmKke3WCfDWGFAEOshrpwSc2b lCQ7nU87CAV3WuMz9wQm645AuhwnDcDkcImlZCm+2jprl/+j0cQ97lAWT0d1z8GU1QC8 voDzBzi98tgdStH+ogW0w7XnnIkLnoc6GJWoaH830M45aHW+ruttOGVT978yBKKiSpcD D4sBetar++7vVgDJvaEq9jxzmA3XxalhW1JxjdEIrTnhoS2DFzLl1HOubouEbUv/NfTk 78Pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697564289; x=1698169089; h=content-transfer-encoding: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=RZKS+tltAUjlfNVIiIJUhREBe4jbMUqPheQI19jdGnw=; b=CtWvL6y+2h6QulN97qR8OeC1dW2E1BvwY5al+XcZScTxE9z9GmmNDGjo9sN7AB4N4S 3q3Z38P9uKGZlXtiHI8YPwAGJOQ9sIXkRpaDOwiwQ27XG6h+f4BfFAg6CCE4OINPGxyN kMV0cjRbWCFh/CKRj+LHqDbXjLUP/VRQUT7QAG7cZMalMoaNAsyyJtuXE6jXEVzn0ov9 T6TiLNdDhz04OGQzqrsGoRLZzG52QSVNnjfkX9ovCU/Kh5YZ98UdyWzUNazrpq02mA9H tobHnyfp6Y8fQgy0eTPOP0vYBSlUe+Cftfk9YbunBiXmY2q6kjypwLLdV2yiLcaE5oLY vuVw== X-Gm-Message-State: AOJu0YzcY4+NB+UtjK5llYTkQvI0j4NMf+yRhtpfs7M44CBg7q2/wfwQ y2T5OmnE9tPcR1aA+kmfEBqfhrg2wtq4ADuywrJXsw== X-Google-Smtp-Source: AGHT+IGW/DfSqjSCbxMZ2JHdWTh4xh9PzqbiAEXCfIgd7XVUU79QjTd1D7Z7Jh/Y9ONjopoJZbfMZ5vRrZ1IksFQpdQ= X-Received: by 2002:a17:90b:5102:b0:27d:3f0c:f087 with SMTP id sc2-20020a17090b510200b0027d3f0cf087mr2927808pjb.25.1697564289498; Tue, 17 Oct 2023 10:38:09 -0700 (PDT) MIME-Version: 1.0 References: <20231016142603.GL4163@brightrain.aerifal.cx> <20231016215307.GE1427497@port70.net> <20231016220410.GM4163@brightrain.aerifal.cx> <20231017082800.GF1427497@port70.net> In-Reply-To: <20231017082800.GF1427497@port70.net> From: Farid Zakaria Date: Tue, 17 Oct 2023 10:37:57 -0700 Message-ID: To: Rich Felker , Farid Zakaria , 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 Here is a link for posterity with the code: https://github.com/fzakaria/musllibc/blob/ea4b030db9dfab2b6163883bf15e33f5b= 22d70f1/ldso/dynlink.c#L1997 For those that are curious how I achieved it. On Tue, Oct 17, 2023 at 1:28=E2=80=AFAM Szabolcs Nagy wrot= e: > > * Rich Felker [2023-10-16 18:04:11 -0400]: > > On Mon, Oct 16, 2023 at 11:53:07PM +0200, Szabolcs Nagy wrote: > > > 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_star= t, > > > then just drop "weak" and the runtime check. (the code as written ass= umes > > > ehdr is not at exact 0 address, which is guaranteed by usual linux se= tups) > > > > Interesting -- perhaps we should find a way to use this in ldso to > > find its own ehdr. > > for that use it is a bit target specific: > the symbol address computation must be pc-relative with no dynamic reloc, > e.g. 'weak' would create a got reloc so not usable before relocs are done= . > > glibc switched using it (but can use auxv too), requires binutils >=3D 2.= 23. > i think lld had issues with setting GOT[0] up with vaddr of _DYNAMIC > which is what glibc was relying on previously on many targets.