From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id BA30DC021B0 for ; Wed, 19 Feb 2025 19:52:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 35597280266; Wed, 19 Feb 2025 14:52:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2682428025B; Wed, 19 Feb 2025 14:52:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0E1F6280266; Wed, 19 Feb 2025 14:52:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id DE1AB28025B for ; Wed, 19 Feb 2025 14:52:17 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 91267B08FE for ; Wed, 19 Feb 2025 19:52:17 +0000 (UTC) X-FDA: 83137740714.20.CEC7BF8 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf25.hostedemail.com (Postfix) with ESMTP id D3013A0005 for ; Wed, 19 Feb 2025 19:52:15 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="B+nvF/kz"; spf=pass (imf25.hostedemail.com: domain of kees@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739994736; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Tl0QYPnYYlggaWp2d/FPXdSL1R6ZG/NDC5TGv1yvGek=; b=d0nDtz2bDkGD9A97Zf2qHJpcn9J6QoszR9N68WyOt7QPm4D9Jo4O2K4KwkxF7Idhp3tFwE XediUf2x7k0rgOS4QfTedy45EtY6SycS1/dA6rx84zSkERR+cJrudoSj/XqOiCfVY7lXdZ tHIpYoq+iaBuY4jPNYOzU3lfjUwNtv4= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="B+nvF/kz"; spf=pass (imf25.hostedemail.com: domain of kees@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739994736; a=rsa-sha256; cv=none; b=hPfo1dMVzCuirFp1nprGlDlO3NrS27Ix8YZ9UXfBb6tm2ObDL1uUgDmpqF0riD1fjSL9ig tgPOY+gpLYK2PMp5fvhZxT5oa/CRuoTu2vbqpihwmzdQxUGsDDyKll5pwUVCXHweSEBiTl 2L8P9E5H9nb577ZQ4hW5Z7lqG6snviw= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id CB1785C5696; Wed, 19 Feb 2025 19:51:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A5D99C4CED1; Wed, 19 Feb 2025 19:52:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1739994734; bh=DOLQO1RhmFhLWn7hxDgAwrHM0OygQR57BvyDe/z/2wI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=B+nvF/kzUx8ChqdNJGi4mLE5l7ace1wA4FRzx2E0rnuH98fibIN30MigbxOXBGOOS 7HiekgYP6+Rn3tqCwgOWIvRfGwzvTxQPLfrLfNotoHBEjop2kGVs8C4T1098tm+UGu wnjLKRz3NbY5b5mL0vhn4/s2ev10wIbZ3Htq0sBijZc15A9hn1bIO9gL+Lju8usPbR jjqWZyY8sNs6aQBOTFKXebmpFKuwtzQxbbSOeoOX8YlKTl0ddB7cOHGgVAPvCHhk0u fYGZoBSBE1lSU79SMxq+EjZtJYpYunCpCaWJZrbuZJq/q1pX9KXzw/dWTpdW6aD31W QgHfoUx6KDaXw== Date: Wed, 19 Feb 2025 11:52:11 -0800 From: Kees Cook To: Jan Kara , Michael Stapelberg , Brian Mak Cc: Christian Brauner , "Eric W. Biederman" , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , Oleg Nesterov , Linus Torvalds , Alexander Viro Subject: Re: [PATCH v3] binfmt_elf: Dump smaller VMAs first in ELF cores Message-ID: <202502191134.CC80931AC9@keescook> References: <036CD6AE-C560-4FC7-9B02-ADD08E380DC9@juniper.net> <20250218085407.61126-1-michael@stapelberg.de> <39FC2866-DFF3-43C9-9D40-E8FF30A218BD@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: D3013A0005 X-Stat-Signature: 6m9emyuwmzrrnab7jg4apcgoig3eieie X-Rspam-User: X-HE-Tag: 1739994735-660985 X-HE-Meta: U2FsdGVkX18FO3JaBpjB+ghp4PQoOOpClcdqyWBPNZuSS6N+jrIwuBM841Q94prw5Q7HkiC74mzI9j49MbQBLHF0lW2+9dYfQOurJxqS2ZxmmCXHghTsWyKuXvwDYie52fmDslUeMKyFex6sr72ttaKvEOdfXMTLyj+t47rYM+9WCnw/jFmGacvas2MlsGgONlkcvyeLXUeYtTihwoLWn/zvBlM6gCiSeDDHJai4jUwg87r5uHpmLYU0rGrP9FDT7rjN7i/A7oLYS79KDoQ3CqbL1ihMt3fhMJHi9TfmF9aO1mMWGblsycwsZ6cJPsnDoLwPWmCE8jCaHAXWFuZ7Qm3+OreyQVQqqS8QcyyCVL97wku0ACdi4XGLcY6KECrms0n8kuLLV/pBakBvNKL82qEhkOhuiiZAj0RejccP0f0hl1HR6wSQOPJchyBOMs3w0bwnZumsRhCgv74hU6Q+ChAkikRYemfQL0I2+zbi++mFvOY868QJCw7vc6SKG5/r6WZrohqifA0k/C0BlGxKYM+6Yag+w1qRhvfFkRNiCk7UdYQp/F7sIbrWorUw94xS8gKtUvYyGTxUM59CCmPzQvER+T3IFwyul4RxPPyXY2GOsfRp58MYJDLMJOkAjl4tqPtaIOJpwAhASpBfoZjKa5WAaRQ8pru3QEcO1W0PcoZqpTcvHU3Lawvwp/GzR51zQXjnSB8V9VCrlfGMNM/ed27J8tNGvLFpZ2qqAThtQ/wL3tSEh/Tvnz+ydJR103SCshcZzV5an88brbJpMnHni3yqpezIa9o8+fP4XzPRp43MjxZmZEM8VldEK+OBV1tZ5pPa28DeJWcy2agDwc1YT2gbKrDN5HoycScYnYOkUBmOP03TIQm9glq5qq+ohXxJ0CR38hitIPiZXgcSohyLDgWxtJ7SLYWOWekI6wG6O8iHrzLJmUJFSpJ13g2UxtWaHNmBJme2UujDTCnWEZd WJe95aOx PrHg67UMJZRekqAdLRfkYVX85fThPTVfb1l7fGdPXmHF9t8yAV7jqDlUby/FngxxXeK4jwN2S6IGF4cNOARgl0y0IdTfCqGICk6vJS04HiaujJWsKhjVg0XjiFjEmcB8E5JcJtJ5G4+l0awjlXsO8q8NpK4530KqbF2IfCXUmkFbpNdKW4IexR12crDtnb/dc8Lyjho874/3GocaaF78GuF0b57yXZAOwF5oOvuG1bmG6hBkxOVbUmreJb0KfoyGubr3i6nMfbiomG/rdFnlqBQ4wQ1szamE81UxEjtbzv+5u7svMnpkKj6bMoA7TTB4jGmqsvD08ALqJMaBRmsI8Uj/ZaLIEjb4BwjD0sGYJd64CRyKu89gfD3+Y3QFsQacDQCiHBsd46V9AsUTTtAwzxXJXVu1Zju+IyWEuE20YJ5En37ZZ1ytnJf5qb8fuQYXxs6pv X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Feb 19, 2025 at 05:20:17PM +0100, Jan Kara wrote: > On Tue 18-02-25 19:53:51, Brian Mak wrote: > > On Feb 18, 2025, at 12:54 AM, Michael Stapelberg wrote: > > > > > I think in your testing, you probably did not try the eu-stack tool > > > from the elfutils package, because I think I found a bug: > > > > Hi Michael, > > > > Thanks for the report. I can confirm that this issue does seem to be > > from this commit. I tested it with Juniper's Linux kernel with and > > without the changes. > > > > You're correct that the original testing done did not include the > > eu-stack tool. > > > > > Current elfutils cannot symbolize core dumps created by Linux 6.12+. > > > I noticed this because systemd-coredump(8) uses elfutils, and when > > > a program crashed on my machine, syslog did not show function names. > > > > > > I reported this issue with elfutils at: > > > https://urldefense.com/v3/__https://sourceware.org/bugzilla/show_bug.cgi?id=32713__;!!NEt6yMaO-gk!DbttKuHxkBdrV4Cj9axM3ED6mlBHXeQGY3NVzvfDlthl-K39e9QIrZcwT8iCXLRu0OivWRGgficcD-aCuus$ > > > …but figured it would be good to give a heads-up here, too. > > > > > > Is this breakage sufficient reason to revert the commit? > > > Or are we saying userspace just needs to be updated to cope? > > > > The way I see it is that, as long as we're in compliance with the > > applicable ELF specifications, then the issue lies with userspace apps > > to ensure that they are not making additional erroneous assumptions. > > > > However, Eric mentioned a while ago in v1 of this patch that he believes > > that the ELF specification requires program headers be written in memory > > order. Digging through the ELF specifications, I found that any loadable > > segment entries in the program header table must be sorted on the > > virtual address of the first byte of which the segment resides in > > memory. > > > > This indicates that we have deviated from the ELF specification with > > this commit. One thing we can do to remedy this is to have program > > headers sorted according to the specification, but then continue dumping > > in VMA size ordering. This would make the dumping logic significantly > > more complex though. > > > > Seeing how most popular userspace apps, with the exception of eu-stack, > > seem to work, we could also just leave it, and tell userspace apps to > > fix it on their end. > > Well, it does not seem eu-stack is that unpopular and we really try hard to > avoid user visible regressions. So I think we should revert the change. Also > the fact that the patch breaks ELF spec is an indication there may be other > tools that would get confused by this and another reason for a revert... Yeah, I think we need to make this a tunable. Updating the kernel breaks elftools, which isn't some weird custom corner case. :P So, while it took a few months, here is a report of breakage that I said we'd need to watch for[1]. :) Is anyone able to test this patch? And Brian will setting a sysctl be okay for your use-case? diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index a43b78b4b646..35d5d86cff69 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -222,6 +222,17 @@ and ``core_uses_pid`` is set, then .PID will be appended to the filename. +core_sort_vma +============= + +The default coredump writes VMAs in address order. By setting +``core_sort_vma`` to 1, VMAs will be written from smallest size +to largest size. This is known to break at least elfutils, but +can be handy when dealing with very large (and truncated) +coredumps where the more useful debugging details are included +in the smaller VMAs. + + ctrl-alt-del ============ diff --git a/fs/coredump.c b/fs/coredump.c index 591700e1b2ce..4375c70144d0 100644 --- a/fs/coredump.c +++ b/fs/coredump.c @@ -63,6 +63,7 @@ static void free_vma_snapshot(struct coredump_params *cprm); static int core_uses_pid; static unsigned int core_pipe_limit; +static unsigned int core_sort_vma; static char core_pattern[CORENAME_MAX_SIZE] = "core"; static int core_name_size = CORENAME_MAX_SIZE; unsigned int core_file_note_size_limit = CORE_FILE_NOTE_SIZE_DEFAULT; @@ -1026,6 +1027,15 @@ static const struct ctl_table coredump_sysctls[] = { .extra1 = (unsigned int *)&core_file_note_size_min, .extra2 = (unsigned int *)&core_file_note_size_max, }, + { + .procname = "core_sort_vma", + .data = &core_sort_vma, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = proc_douintvec_minmax, + .extra1 = SYSCTL_ZERO, + .extra2 = SYSCTL_ONE, + }, }; static int __init init_fs_coredump_sysctls(void) @@ -1256,8 +1266,9 @@ static bool dump_vma_snapshot(struct coredump_params *cprm) cprm->vma_data_size += m->dump_size; } - sort(cprm->vma_meta, cprm->vma_count, sizeof(*cprm->vma_meta), - cmp_vma_size, NULL); + if (core_sort_vma) + sort(cprm->vma_meta, cprm->vma_count, sizeof(*cprm->vma_meta), + cmp_vma_size, NULL); return true; } -Kees [1] https://lore.kernel.org/all/202408092104.FCE51021@keescook/ -- Kees Cook