From: Brian Mak <makb@juniper.net>
To: Michael Stapelberg <michael@stapelberg.ch>
Cc: Christian Brauner <brauner@kernel.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Jan Kara <jack@suse.cz>, Kees Cook <kees@kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Oleg Nesterov <oleg@redhat.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Alexander Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH v3] binfmt_elf: Dump smaller VMAs first in ELF cores
Date: Tue, 18 Feb 2025 19:53:51 +0000 [thread overview]
Message-ID: <39FC2866-DFF3-43C9-9D40-E8FF30A218BD@juniper.net> (raw)
In-Reply-To: <20250218085407.61126-1-michael@stapelberg.de>
On Feb 18, 2025, at 12:54 AM, Michael Stapelberg <michael@stapelberg.ch> 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.
Eric and Kees, thoughts? I'm open to going either way.
Best,
Brian
next prev parent reply other threads:[~2025-02-18 19:54 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <036CD6AE-C560-4FC7-9B02-ADD08E380DC9@juniper.net>
[not found] ` <CAHk-=wh_P7UR6RiYmgBDQ4L-kgmmLMziGarLsx_0bUn5vYTJUw@mail.gmail.com>
2024-08-09 14:39 ` Eric W. Biederman
2024-08-09 15:13 ` Linus Torvalds
[not found] ` <172300808013.2419749.16446009147309523545.b4-ty@kernel.org>
2024-08-10 0:52 ` Brian Mak
2024-08-10 4:06 ` Kees Cook
2024-08-10 12:28 ` Eric W. Biederman
2024-08-12 18:05 ` Kees Cook
2024-08-12 18:21 ` Brian Mak
2024-08-12 18:25 ` Kees Cook
2025-02-18 8:54 ` Michael Stapelberg
2025-02-18 19:53 ` Brian Mak [this message]
2025-02-19 13:28 ` Sam James
2025-02-19 16:20 ` Jan Kara
2025-02-19 19:52 ` Kees Cook
2025-02-19 20:38 ` Brian Mak
2025-02-22 2:13 ` Brian Mak
2025-02-22 14:51 ` Kees Cook
2025-02-20 0:23 ` Brian Mak
2025-02-20 0:39 ` Linus Torvalds
2025-02-20 1:36 ` Kees Cook
2025-02-20 22:59 ` Brian Mak
2025-02-22 15:15 ` Kees Cook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=39FC2866-DFF3-43C9-9D40-E8FF30A218BD@juniper.net \
--to=makb@juniper.net \
--cc=brauner@kernel.org \
--cc=ebiederm@xmission.com \
--cc=jack@suse.cz \
--cc=kees@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=michael@stapelberg.ch \
--cc=oleg@redhat.com \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox