Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 6 May 2019 13:14:16 +0200
From: Christian Brauner <>
To: Jann Horn <>
Cc: Solar Designer <>,
	Kernel Hardening <>
Subject: Re: race-free process signaling

On Mon, May 06, 2019 at 12:45:14PM +0200, Jann Horn wrote:
> +cc Christian Brauner (author of pidfd code)
> On Mon, May 6, 2019 at 12:22 PM Solar Designer <> wrote:
> > I totally missed the recent work in this area (I'm not on LKML),
> FWIW, you don't usually need to actually read LKML to see when major
> developments happen - I read LWN, which seems to work pretty well for
> that purpose.
> > and am
> > now wondering whether the solution that got in ("use /proc/<pid> fds as
> > stable handles on struct pid"):
> >
> >
> >
> >
> > is better or worse than what I had proposed in 1999 and 2005 ("locking"
> > of pids for the caller's own visibility only):
> >
> >
> >
> > [Subject starts with "PID reuse safety for userspace apps", in case MARC
> > is ever gone and someone wants to look this up in another archive.
> (The kernel people now have as an email archive, which
> is much nicer to use IMO - it has search, it has a nice thread view,
> and you can download raw mbox files if you want to reply to a mail:
> <>)
> > I proposed a lockpid syscall back then, but I'd use a mere prctl now.]
> >
> > I still like my proposal much better - no dependency on procfs, much

This has always been the goal and with the new CLONE_PIDFD flag we make
this possible. I'm about to send the PR for this merge window.
/proc/<pid> fds stay behind as a convenience for pidfd_send_signal()
only with no new features added to them.
There is some (tedious) historical context why it came to be that way.
My original implementation was already different. 
pidfd_send_signal() was basically based on /proc/<pid> fd because some
developers had opposed other solutions since the /proc/<pid> idea seemed
so "simple".
The truth is it gets very very problematic when you think about
returning fds at process creation time. This is why pidfds will be anon

> > simpler implementation - but perhaps I'm missing the context here.
> Actually, there is ongoing development of pidfd stuff, including
> procfs-less pidfds. You may want to look through
> <>, or something like that.
> The following series adds anon-inode-based pidfds that can be returned
> from sys_clone():
> "[PATCH v3 2/4] clone: add CLONE_PIDFD"
> <>
> "[PATCH v3 3/4] signal: support CLONE_PIDFD with pidfd_send_signal"
> <>
> This patch adds process exit notifications that can be received
> through the normal file polling syscalls (epoll/poll/select/...):
> "[PATCH v2 1/2] Add polling support to pidfd"
> <>
> > Maybe I should have sent a patch back then.  Oh well.

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.