linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Brian Mak <makb@juniper.net>
Cc: Michael Stapelberg <michael@stapelberg.ch>,
	 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: Wed, 19 Feb 2025 17:20:17 +0100	[thread overview]
Message-ID: <a3owf3zywbnntq4h4eytraeb6x7f77lpajszzmsy5d7zumg3tk@utzxmomx6iri> (raw)
In-Reply-To: <39FC2866-DFF3-43C9-9D40-E8FF30A218BD@juniper.net>

On Tue 18-02-25 19:53:51, Brian Mak wrote:
> 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.

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...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR


  parent reply	other threads:[~2025-02-19 16:20 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
2025-02-19 13:28     ` Sam James
2025-02-19 16:20     ` Jan Kara [this message]
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=a3owf3zywbnntq4h4eytraeb6x7f77lpajszzmsy5d7zumg3tk@utzxmomx6iri \
    --to=jack@suse.cz \
    --cc=brauner@kernel.org \
    --cc=ebiederm@xmission.com \
    --cc=kees@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=makb@juniper.net \
    --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