Date: Mon, 6 May 2019 12:45:14 +0200 From: Jann Horn <jannh@...gle.com> To: Solar Designer <solar@...nwall.com> Cc: Kernel Hardening <kernel-hardening@...ts.openwall.com>, Christian Brauner <christian@...uner.io> Subject: Re: race-free process signaling +cc Christian Brauner (author of pidfd code) On Mon, May 6, 2019 at 12:22 PM Solar Designer <solar@...nwall.com> 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"): > > https://lwn.net/Articles/773459/ > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a9dce6679d736cb3d612af39bab9f31f8db66f9b > > is better or worse than what I had proposed in 1999 and 2005 ("locking" > of pids for the caller's own visibility only): > > https://marc.info/?l=linux-kernel&m=112784189115058 > > [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 lore.kernel.org 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: <https://lore.kernel.org/lkml/20050927172048.GA3423@openwall.com/>) > 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 > 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 <https://lore.kernel.org/lkml/?q=f%3Abrauner>, 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" <https://firstname.lastname@example.org/> "[PATCH v3 3/4] signal: support CLONE_PIDFD with pidfd_send_signal" <https://email@example.com/> 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" <https://firstname.lastname@example.org/> > 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.