From: Nir Lichtman <nir@lichtman.org>
To: Kees Cook <kees@kernel.org>
Cc: viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz,
ebiederm@xmission.com, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] exec: remove redundant save asides of old pid/vpid
Date: Sat, 1 Feb 2025 11:03:02 +0000 [thread overview]
Message-ID: <20250201110302.GA1186433@lichtman.org> (raw)
In-Reply-To: <0B25310A-0907-481E-8ADF-EEFA78927BFF@kernel.org>
On Sat, Feb 01, 2025 at 01:40:00AM -0800, Kees Cook wrote:
>
>
> On February 1, 2025 12:31:27 AM PST, Nir Lichtman <nir@lichtman.org> wrote:
> >Problem: Old pid and vpid are redundantly saved aside before starting to
> >parse the binary, with the comment claiming that it is required since
> >load_binary changes it, though from inspection in the source,
> >load_binary does not change the pid and this wouldn't make sense since
> >execve does not create any new process, quote from man page of execve:
> >"there is no new process; many attributes of the calling process remain
> >unchanged (in particular, its PID)."
>
> See commit bb188d7e64de ("ptrace: make former thread ID available via PTRACE_GETEVENTMSG after PTRACE_EVENT_EXEC stop")
>
> This is for making sense of a concurrent exec made by a multi threaded process. Specifically see de_thread(), where the pid *can* change:
>
> /*
> * At this point all other threads have exited, all we have to
> * do is to wait for the thread group leader to become inactive,
> * and to assume its PID:
> */
>
> The described problem in the commit hasn't changed, so this code needs to stay as-is. Or perhaps the comment could be improved?
Thanks for answering, interesting, I'll take a deeper look.
Nir
prev parent reply other threads:[~2025-02-01 11:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-01 8:31 [PATCH] exec: remove redundant save asides of old pid/vpid Nir Lichtman
2025-02-01 9:40 ` Kees Cook
2025-02-01 11:03 ` Nir Lichtman [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=20250201110302.GA1186433@lichtman.org \
--to=nir@lichtman.org \
--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=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 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.