From: Jann Horn <jannh@google.com>
To: Christian Brauner <brauner@kernel.org>
Cc: linux-fsdevel@vger.kernel.org,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Kuniyuki Iwashima" <kuniyu@amazon.com>,
"Eric Dumazet" <edumazet@google.com>,
"Oleg Nesterov" <oleg@redhat.com>,
"David S. Miller" <davem@davemloft.net>,
"Alexander Viro" <viro@zeniv.linux.org.uk>,
"Daan De Meyer" <daan.j.demeyer@gmail.com>,
"David Rheinsberg" <david@readahead.eu>,
"Jakub Kicinski" <kuba@kernel.org>, "Jan Kara" <jack@suse.cz>,
"Lennart Poettering" <lennart@poettering.net>,
"Luca Boccassi" <bluca@debian.org>, "Mike Yuan" <me@yhndnzj.com>,
"Paolo Abeni" <pabeni@redhat.com>,
"Simon Horman" <horms@kernel.org>,
"Zbigniew Jędrzejewski-Szmek" <zbyszek@in.waw.pl>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-security-module@vger.kernel.org,
"Alexander Mikhalitsyn" <alexander@mihalicyn.com>
Subject: Re: [PATCH v7 5/9] pidfs, coredump: add PIDFD_INFO_COREDUMP
Date: Thu, 15 May 2025 23:37:37 +0200 [thread overview]
Message-ID: <CAG48ez33kd=KFKfxNN1Z-xwrCvrHSNumJ-YbDmke0GM2a3tv0g@mail.gmail.com> (raw)
In-Reply-To: <CAG48ez3-=B1aTftz0srNjV7_t6QqGuk41LFAe6_qeXtXWL3+PA@mail.gmail.com>
On Thu, May 15, 2025 at 10:56 PM Jann Horn <jannh@google.com> wrote:
> On Thu, May 15, 2025 at 12:04 AM Christian Brauner <brauner@kernel.org> wrote:
> > Extend the PIDFD_INFO_COREDUMP ioctl() with the new PIDFD_INFO_COREDUMP
> > mask flag. This adds the fields @coredump_mask and @coredump_cookie to
> > struct pidfd_info.
>
> FWIW, now that you're using path-based sockets and override_creds(),
> one option may be to drop this patch and say "if you don't want
> untrusted processes to directly connect to the coredumping socket,
> just set the listening socket to mode 0000 or mode 0600"...
Er, forget I said that, of course we'd still want to have at least the
@coredump_mask.
> > Signed-off-by: Christian Brauner <brauner@kernel.org>
> [...]
> > diff --git a/fs/coredump.c b/fs/coredump.c
> > index e1256ebb89c1..bfc4a32f737c 100644
> > --- a/fs/coredump.c
> > +++ b/fs/coredump.c
> [...]
> > @@ -876,8 +880,34 @@ void do_coredump(const kernel_siginfo_t *siginfo)
> > goto close_fail;
> > }
> >
> > + /*
> > + * Set the thread-group leader pid which is used for the
> > + * peer credentials during connect() below. Then
> > + * immediately register it in pidfs...
> > + */
> > + cprm.pid = task_tgid(current);
> > + retval = pidfs_register_pid(cprm.pid);
> > + if (retval) {
> > + sock_release(socket);
> > + goto close_fail;
> > + }
> > +
> > + /*
> > + * ... and set the coredump information so userspace
> > + * has it available after connect()...
> > + */
> > + pidfs_coredump(&cprm);
> > +
> > + /*
> > + * ... On connect() the peer credentials are recorded
> > + * and @cprm.pid registered in pidfs...
>
> I don't understand this comment. Wasn't "@cprm.pid registered in
> pidfs" above with the explicit `pidfs_register_pid(cprm.pid)`?
>
> > + */
> > retval = kernel_connect(socket, (struct sockaddr *)(&addr),
> > addr_len, O_NONBLOCK | SOCK_COREDUMP);
> > +
> > + /* ... So we can safely put our pidfs reference now... */
> > + pidfs_put_pid(cprm.pid);
>
> Why can we safely put the pidfs reference now but couldn't do it
> before the kernel_connect()? Does the kernel_connect() look up this
> pidfs entry by calling something like pidfs_alloc_file()? Or does that
> only happen later on, when the peer does getsockopt(SO_PEERPIDFD)?
>
> > if (retval) {
> > if (retval == -EAGAIN)
> > coredump_report_failure("Coredump socket %s receive queue full", addr.sun_path);
> [...]
> > diff --git a/fs/pidfs.c b/fs/pidfs.c
> > index 3b39e471840b..d7b9a0dd2db6 100644
> > --- a/fs/pidfs.c
> > +++ b/fs/pidfs.c
> [...]
> > @@ -280,6 +299,13 @@ static long pidfd_info(struct file *file, unsigned int cmd, unsigned long arg)
> > }
> > }
> >
> > + if (mask & PIDFD_INFO_COREDUMP) {
> > + kinfo.mask |= PIDFD_INFO_COREDUMP;
> > + smp_rmb();
>
> I assume I would regret it if I asked what these barriers are for,
> because the answer is something terrifying about how we otherwise
> don't have a guarantee that memory accesses can't be reordered between
> multiple subsequent syscalls or something like that?
>
> checkpatch complains about the lack of comments on these memory barriers.
>
> > + kinfo.coredump_cookie = READ_ONCE(pidfs_i(inode)->__pei.coredump_cookie);
> > + kinfo.coredump_mask = READ_ONCE(pidfs_i(inode)->__pei.coredump_mask);
> > + }
> > +
> > task = get_pid_task(pid, PIDTYPE_PID);
> > if (!task) {
> > /*
> [...]
> > diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
> > index a9d1c9ba2961..053d2e48e918 100644
> > --- a/net/unix/af_unix.c
> > +++ b/net/unix/af_unix.c
> [...]
> > @@ -742,6 +743,7 @@ static void unix_release_sock(struct sock *sk, int embrion)
> >
> > struct unix_peercred {
> > struct pid *peer_pid;
> > + u64 cookie;
>
> Maybe add a comment here documenting that for now, this is assumed to
> be used exclusively for coredump sockets.
>
>
> > const struct cred *peer_cred;
> > };
> >
next prev parent reply other threads:[~2025-05-15 21:38 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-14 22:03 [PATCH v7 0/9] coredump: add coredump socket Christian Brauner
2025-05-14 22:03 ` [PATCH v7 1/9] coredump: massage format_corname() Christian Brauner
2025-05-15 13:19 ` Alexander Mikhalitsyn
2025-05-15 13:36 ` Serge E. Hallyn
2025-05-15 20:52 ` Jann Horn
2025-05-14 22:03 ` [PATCH v7 2/9] coredump: massage do_coredump() Christian Brauner
2025-05-15 13:21 ` Alexander Mikhalitsyn
2025-05-15 20:52 ` Jann Horn
2025-05-14 22:03 ` [PATCH v7 3/9] coredump: reflow dump helpers a little Christian Brauner
2025-05-15 13:22 ` Alexander Mikhalitsyn
2025-05-15 20:53 ` Jann Horn
2025-05-14 22:03 ` [PATCH v7 4/9] coredump: add coredump socket Christian Brauner
2025-05-15 13:47 ` Alexander Mikhalitsyn
2025-05-16 8:30 ` Christian Brauner
2025-05-15 17:00 ` Kuniyuki Iwashima
2025-05-15 20:52 ` Jann Horn
2025-05-15 21:04 ` Kuniyuki Iwashima
2025-05-16 10:14 ` Christian Brauner
2025-05-15 20:54 ` Jann Horn
2025-05-15 21:15 ` Kuniyuki Iwashima
2025-05-16 10:09 ` Christian Brauner
2025-05-16 10:20 ` Christian Brauner
2025-05-14 22:03 ` [PATCH v7 5/9] pidfs, coredump: add PIDFD_INFO_COREDUMP Christian Brauner
2025-05-15 14:08 ` Alexander Mikhalitsyn
2025-05-15 20:56 ` Jann Horn
2025-05-15 21:37 ` Jann Horn [this message]
2025-05-16 10:34 ` Christian Brauner
2025-05-16 14:26 ` Jann Horn
2025-05-14 22:03 ` [PATCH v7 6/9] coredump: show supported coredump modes Christian Brauner
2025-05-15 13:56 ` Alexander Mikhalitsyn
2025-05-15 20:56 ` Jann Horn
2025-05-14 22:03 ` [PATCH v7 7/9] coredump: validate socket name as it is written Christian Brauner
2025-05-15 14:03 ` Alexander Mikhalitsyn
2025-05-15 20:56 ` Jann Horn
2025-05-16 9:54 ` Christian Brauner
2025-05-16 13:29 ` Christian Brauner
2025-05-14 22:03 ` [PATCH v7 8/9] selftests/pidfd: add PIDFD_INFO_COREDUMP infrastructure Christian Brauner
2025-05-15 14:35 ` Alexander Mikhalitsyn
2025-05-14 22:03 ` [PATCH v7 9/9] selftests/coredump: add tests for AF_UNIX coredumps Christian Brauner
2025-05-15 14:37 ` Alexander Mikhalitsyn
2025-05-14 22:38 ` [PATCH v7 0/9] coredump: add coredump socket Luca Boccassi
2025-05-15 9:17 ` Christian Brauner
2025-05-15 9:26 ` Lennart Poettering
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='CAG48ez33kd=KFKfxNN1Z-xwrCvrHSNumJ-YbDmke0GM2a3tv0g@mail.gmail.com' \
--to=jannh@google.com \
--cc=alexander@mihalicyn.com \
--cc=bluca@debian.org \
--cc=brauner@kernel.org \
--cc=daan.j.demeyer@gmail.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=david@readahead.eu \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jack@suse.cz \
--cc=kuba@kernel.org \
--cc=kuniyu@amazon.com \
--cc=lennart@poettering.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=me@yhndnzj.com \
--cc=netdev@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=pabeni@redhat.com \
--cc=viro@zeniv.linux.org.uk \
--cc=zbyszek@in.waw.pl \
/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;
as well as URLs for NNTP newsgroup(s).