linux-kernel - Re: [PATCH v3] binfmt_elf: Dump smaller VMAs first in ELF cores

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <39FC2866-DFF3-43C9-9D40-E8FF30A218BD@juniper.net>
Date: Tue, 18 Feb 2025 19:53:51 +0000
From: Brian Mak <makb@...iper.net>
To: Michael Stapelberg <michael@...pelberg.ch>
CC: Christian Brauner <brauner@...nel.org>,
        "Eric W. Biederman"
	<ebiederm@...ssion.com>, Jan Kara <jack@...e.cz>,
        Kees Cook
	<kees@...nel.org>,
        "linux-fsdevel@...r.kernel.org"
	<linux-fsdevel@...r.kernel.org>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        Oleg Nesterov <oleg@...hat.com>,
        Linus Torvalds
	<torvalds@...ux-foundation.org>,
        Alexander Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH v3] binfmt_elf: Dump smaller VMAs first in ELF cores

On Feb 18, 2025, at 12:54 AM, Michael Stapelberg <michael@...pelberg.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