From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by sourceware.org (Postfix) with ESMTPS id 81BE53858D1E for ; Sun, 31 Dec 2023 05:16:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 81BE53858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dxuuu.xyz Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dxuuu.xyz ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 81BE53858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=66.111.4.28 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703999806; cv=none; b=brqv2tDqHU+5OyGUzEmHxef0j6dk6xDkfKF201xYAezxV8T+gW7GIKuAknwUctT6N3PhbIgLtdm6vkVOGN4ptlq91C5SAHwlwr49C0zV/ytSgvNjZPP2v4rZlqq91rZPhbR2lVvXcmx7h1NgNlWpvapLL9+n2X+ZiWpb8yp4Ayw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703999806; c=relaxed/simple; bh=q0qgBY532YP/5MNpg/iZ9nhzIJMtNiY8jMNfwwbEL4k=; h=DKIM-Signature:DKIM-Signature:MIME-Version:Message-Id:Date:From: To:Subject; b=BTkaWvK6Ar4dPmTIo1Z2KXoKOFj8n3XTkuITJgN8WoL/y0oVOAacdo/YDTFgHzm3zPsozt2sjh3MqNUjmpZz4sL76Jlku9ai7TIPapHx261nlDpjECPa56adJdqrrF6owKzHrWVGIggHaX1kYfSKiFdo5Z4ypyZxWK9cjd1UmNo= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 5CA095C00B7; Sun, 31 Dec 2023 00:16:42 -0500 (EST) Received: from imap42 ([10.202.2.92]) by compute4.internal (MEProxy); Sun, 31 Dec 2023 00:16:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dxuuu.xyz; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1703999802; x=1704086202; bh=KjR2GIhQYE jKR5qy5c5RARsbseVJFxPsz7iw98bzr6k=; b=PE/fSOpPxEE58F1qzj2p5Qde9D WRW8VjaNH9wWyseNLuidRbm5NGSymnUAopBstE7WkomDgNOCaXW+72JqolelHZON iIQxVqjOsDS3D54B7AW/nan/6f21dogDQq1HpTJFVslbk+01BAmYqoohWoiQ++Yd mWUm2EcFuwfuLqDngXpHueIMVkCc5MBzf7ylJ4myTxp518e0Z5U2JApKhh++bINt 1/Kn5SKF+FHgNmWT4DJhhA7dJchr5+jVeejIS0Rvi3DPtQLkTRGseJ0lgZxk0ANA t/yD+hPFab3Fb5TKv+CCTaJmRKcEXHd2mcH61ZRTYjUtcubydqviot+WealQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1703999802; x=1704086202; bh=KjR2GIhQYEjKR5qy5c5RARsbseVJ FxPsz7iw98bzr6k=; b=hExfxOMj8S2x/rM2QE4DAgXNVE02pvvVCSKzhi8689mQ MSvbVpP+AW/05xLflnfT1JijlqaaLTnr5Hxrd8BOtFBjhK4XjQLueaFfU4KuukVj gweImZRaWp8dOO/gAeSccCPs1xlOU5ZAP2qZ5JlzvBYdtR6mSPxc5lrnRZwYUyl1 HLa1HrOd1+tqR9NYZs/PJW96D4pHU0yq3uZgyZYn1YVB3eapQj2ZKpaG7o994jJ3 /dDxdj2LAvArthAU/XTPayuKpTe3HmWIaZlnp9AVvN8Gta5rnao1k0WZ6/mwndND yktQtVaiutQGcn0RFznGjBiUj6QCC1OUgtyYqyQQrA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdefiedgkeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne gfrhhlucfvnfffucdlfeehmdenucfjughrpefofgggkfgjfhffhffvvefutgesthdtredt reertdenucfhrhhomhepfdffrghnihgvlhcuighufdcuoegugihusegugihuuhhurdighi iiqeenucggtffrrghtthgvrhhnpefgtdevhfdvgedtjeeggfejtedvgeffhfejleekiedu leeuvddvgeeuffffleehleenucffohhmrghinhepghhithhhuhgsrdgtohhmnecuvehluh hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepugiguhesugiguhhu uhdrgiihii X-ME-Proxy: Feedback-ID: i6a694271:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id E9E41BC007D; Sun, 31 Dec 2023 00:16:41 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-1364-ga51d5fd3b7-fm-20231219.001-ga51d5fd3 MIME-Version: 1.0 Message-Id: In-Reply-To: <20231230174101.GC9034@gnu.wildebeest.org> References: <43591825-18a6-4dbd-b27c-fa96d150dc31@app.fastmail.com> <20231230174101.GC9034@gnu.wildebeest.org> Date: Sat, 30 Dec 2023 23:16:21 -0600 From: "Daniel Xu" To: "Mark Wielaard" Cc: elfutils-devel@sourceware.org Subject: Re: Noop round trip through elf_update() causes segfaults Content-Type: text/plain X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,KAM_INFOUSMEBIZ,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Mark, On Sat, Dec 30, 2023, at 11:41 AM, Mark Wielaard wrote: > Hi Daniel, > > On Wed, Dec 27, 2023 at 08:40:09PM -0600, Daniel Xu wrote: >> I was working on code that adds an ELF section containing custom >> metadata to ELF binaries when I started getting odd segfaults >> in the added-to binary. >> >> I've managed to create a minimal reproducer with a couple interesting >> discoveries. The reproducer is available here: >> >> https://github.com/danobi/elf-segfault >> >> Basically it does a noop round trip between elf_begin() and elf_update(). >> But the resulting binary, when run, outputs: >> >> $ ./testprog_copy >> fish: Job 1, './testprog_copy' terminated by signal SIGSEGV (Address boundary error) >> >> Furthermore, I built and ran tests/addsections.c [0] against my testbinary >> and I still get: >> >> $ ./testprog_copy_elfutils >> fish: Job 1, './testprog_copy_elfutils' terminated by signal SIGSEGV (Address boundary error) >> >> I've also tried linking against upstream libelf built from source >> with the same results. >> >> This leads me to believe I'm doing something very wrong or >> I'm hitting a bug. > > You aren't doing something very wrong, but libelf does something you > aren't expecting. When you are calling elf_update () it will rearrange > the elf sections making sure there are no unnecessary gaps between the > sections in the file, that alignment is correct, etc. > > libelf only cares about the section headers. It doesn't know/care > about the program headers. The program headers describe how the > segments have to be loaded at runtime. Since some data has moved > around the program data isn't loaded correctly anymore which causes > the crash. > > To prevent libelf from doing this, and take responsibility of how the > sections are layed out yourself you have to call: > > elf_flagelf (elf, ELF_C_SET, ELF_F_LAYOUT); > > Before calling elf_update. Note that in that case you are responsible > for setting/updating the sh_offset fields of the Shdrs yourself. > > See for example the elfutils src/elfcompress.c program to see what it > does in case the Elf file has program headers. > > Hope that helps, Thanks for taking a look! I did not know about this behavior - this was indeed helpful. Daniel