From: Jann Horn <jannh@google.com>
To: Bill Messmer <wmessmer@microsoft.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Randy Dunlap <rdunlap@infradead.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: Issue With Kernel Changes To Core Dump Collection (Kernel Bug...?)
Date: Fri, 21 Jan 2022 19:39:11 +0100 [thread overview]
Message-ID: <CAG48ez0Om2MD9nn-NSPjtNvQ4DCX=Xakk+A2CqgXcOwxPzPNKQ@mail.gmail.com> (raw)
In-Reply-To: <2e7a440f-b942-2794-6c15-66baf81801ae@infradead.org>
On Fri, Jan 21, 2022 at 7:18 PM Randy Dunlap <rdunlap@infradead.org> wrote:
> On 1/20/22 17:31, Bill Messmer wrote:
> > Hello,
> >
> > It has been my understanding for some time that the kernel config option CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS (and the corresponding bit 4 of the coredump filter) was, at one point, added for the purpose of ensuring that the GNU build-id of ELF objects was included in core dumps. The config description in Kconfig.binfmt even alludes to this in its description.
> >
> > I am trying to understand why in the 5.10+ kernels, there was a change in the kernel that, instead of checking whether a given memory mapping had an ELF header in order to determine whether to include the page to checking whether the inode is executable. The change in question:
> >
> > github.com/torvalds/linux/commit/429a22e776a2b9f85a2b9c53d8e647598b553dd1
As the commit message says, it was an attempt to avoid a deadlock
without making the code overly complicated. Clearly that didn't go as
planned...
> > In many distributions (e.g.: Ubuntu), the shared objects in /usr/lib and elsewhere are not marked as executable.
Urgh, crap. I'm looking around on my Debian box now, and I also see
that some libraries (like ld.so and libc) are marked executable, but
many others are not...
[...]
> > Was the change here really the intent...? or is this a kernel bug?
Yeah, that's a bug. Linus suggested it as a way to simplify my
original patch (https://lore.kernel.org/all/CAHk-=wiOqR-4jXpPe-5PBKSCwQQFDaiJwkJr6ULwhcN8DJoG0A@mail.gmail.com/)
and it seemed like a good idea to me...
I guess the good news is that the original patch
https://lore.kernel.org/all/20200818061239.29091-5-jannh@google.com/
already has the code for doing it properly, so it should be pretty
straightforward to fix this by just pasting over some bits from the
old patch... I'll try to get around to that soon.
This would be so much nicer if the kernel actually knew what is a
library mapping and what isn't... oh well.
prev parent reply other threads:[~2022-01-21 18:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-21 1:31 Issue With Kernel Changes To Core Dump Collection (Kernel Bug...?) Bill Messmer
2022-01-21 18:17 ` Randy Dunlap
2022-01-21 18:39 ` Jann Horn [this message]
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='CAG48ez0Om2MD9nn-NSPjtNvQ4DCX=Xakk+A2CqgXcOwxPzPNKQ@mail.gmail.com' \
--to=jannh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rdunlap@infradead.org \
--cc=torvalds@linux-foundation.org \
--cc=wmessmer@microsoft.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.