From: Jann Horn <jannh@google.com> To: Christian Brauner <christian@brauner.io> Cc: Andy Lutomirski <luto@kernel.org>, David Howells <dhowells@redhat.com>, "Serge E. Hallyn" <serge@hallyn.com>, Linux API <linux-api@vger.kernel.org>, kernel list <linux-kernel@vger.kernel.org>, Arnd Bergmann <arnd@arndb.de>, "Eric W. Biederman" <ebiederm@xmission.com>, Konstantin Khlebnikov <khlebnikov@yandex-team.ru>, Kees Cook <keescook@chromium.org>, Alexey Dobriyan <adobriyan@gmail.com>, Thomas Gleixner <tglx@linutronix.de>, Michael Kerrisk-manpages <mtk.manpages@gmail.com>, Jonathan Kowalski <bl0pbl33p@gmail.com>, "Dmitry V. Levin" <ldv@altlinux.org>, Andrew Morton <akpm@linux-foundation.org>, Oleg Nesterov <oleg@redhat.com>, Nagarathnam Muthusamy <nagarathnam.muthusamy@oracle.com>, Aleksa Sarai <cyphar@cyphar.com>, Al Viro <viro@zeniv.linux.org.uk>, "Joel Fernandes (Google)" <joel@joelfernandes.org>, Daniel Colascione <dancol@google.com>, Florian Weimer <fweimer@redhat.com> Subject: Re: [PATCH v2 4/5] signal: PIDFD_SIGNAL_TID threads via pidfds Date: Sat, 30 Mar 2019 02:06:34 +0100 [thread overview] Message-ID: <CAG48ez0=Q2CzgTGLiEU7F9B=gS-58VrpKz2XQ369cemo2FJdbQ@mail.gmail.com> (raw) In-Reply-To: <20190329155425.26059-5-christian@brauner.io> On Fri, Mar 29, 2019 at 4:54 PM Christian Brauner <christian@brauner.io> wrote: > With the addition of pidfd_open() it is possible for users to reference a > specific thread by doing: > > int pidfd = pidfd_open(<tid>, 0); > > This means we can extend pidfd_send_signal() to signal a specific thread. > As promised in the commit for pidfd_send_signal() [1] the extension is > based on a flag argument, i.e. the scope of the signal delivery is based on > the flag argument, not on the type of file descriptor. > To this end the flag PIDFD_SIGNAL_TID is added. With this change we now > cover most of the functionality of all the other signal sending functions > combined: [...] > diff --git a/include/uapi/linux/wait.h b/include/uapi/linux/wait.h > index d6c7c0701997..b72f0ef84fe5 100644 > --- a/include/uapi/linux/wait.h > +++ b/include/uapi/linux/wait.h [...] > +/* Flags to pass to pidfd_send_signal */ > +#define PIDFD_SIGNAL_TID 1 /* Send signal to specific thread */ nit: s/1/1U/; the flags argument is an `unsigned int` > #endif /* _UAPI_LINUX_WAIT_H */ > diff --git a/kernel/signal.c b/kernel/signal.c > index eb97d0cc6ef7..9f93da85b2b9 100644 > --- a/kernel/signal.c > +++ b/kernel/signal.c [...] > +static int pidfd_send_signal_specific(struct pid *pid, int sig, > + struct kernel_siginfo *info) > +{ > + struct task_struct *p; > + int error = -ESRCH; > + > + rcu_read_lock(); > + p = pid_task(pid, PIDTYPE_PID); > + if (p) > + error = __do_send_specific(p, sig, info); > + rcu_read_unlock(); > + > + return error; > +} > + > /** > - * sys_pidfd_send_signal - send a signal to a process through a task file > - * descriptor > + * sys_pidfd_send_signal - send a signal to a process through a pidfd > + > * @pidfd: the file descriptor of the process > * @sig: signal to be sent > * @info: the signal info > * @flags: future flags to be passed nit: comment is outdated, it isn't "future flags" anymore [...] > + * rt_tgsigqueueinfo(<tgid>, <tid>, <sig>, <uinfo>) > + * - pidfd_send_signal(<pidfd>, <sig>, <info>, PIDFD_SIGNAL_TID); > + * which is equivalent to > + * rt_tgsigqueueinfo(<tgid>, <tid>, <sig>, <uinfo>) > + * > * In order to extend the syscall to threads and process groups the @flags > * argument should be used. In essence, the @flags argument will determine > * what is signaled and not the file descriptor itself. Put in other words, nit: again, outdated comment about @flags [...] > @@ -3626,43 +3695,16 @@ SYSCALL_DEFINE4(pidfd_send_signal, int, pidfd, int, sig, > prepare_kill_siginfo(sig, &kinfo); > } > > - ret = kill_pid_info(sig, &kinfo, pid); > + if (flags & PIDFD_SIGNAL_TID) > + ret = pidfd_send_signal_specific(pid, sig, &kinfo); > + else > + ret = kill_pid_info(sig, &kinfo, pid); nit: maybe give pidfd_send_signal_specific() and kill_pid_info() the same signatures, since they perform similar operations with the same argument types? Something that was already kinda weird in the existing code, but is getting worse with TIDs is the handling of SI_USER with siginfo. Copying context lines from above here: if (info) { ret = copy_siginfo_from_user_any(&kinfo, info); if (unlikely(ret)) goto err; ret = -EINVAL; if (unlikely(sig != kinfo.si_signo)) goto err; if ((task_pid(current) != pid) && (kinfo.si_code >= 0 || kinfo.si_code == SI_TKILL)) { /* Only allow sending arbitrary signals to yourself. */ ret = -EPERM; if (kinfo.si_code != SI_USER) goto err; /* Turn this into a regular kill signal. */ prepare_kill_siginfo(sig, &kinfo); } } else { prepare_kill_siginfo(sig, &kinfo); } So for signals to PIDs, the rule is that if you send siginfo with SI_USER to yourself, the siginfo is preserved; otherwise the kernel silently clobbers it. That's already kind of weird - silent behavior difference depending on a security check. But now, for signals to threads, I think the result is going to be that signalling the thread group leader preserves information, and signalling any other thread clobbers it? If so, that seems bad. do_rt_sigqueueinfo() seems to have the same issue, from a glance - but there, at least the error case is just a -EPERM, not a silent behavior difference. Would it make sense to refuse sending siginfo with SI_USER to non-current? If you actually want to send a normal SI_USER signal, you can use info==NULL, right? That should create wrongness parity with do_rt_sigqueueinfo(). To improve things further, I guess you'd have to move the comparison against current into pidfd_send_signal_specific(), or move the task lookup out of it, or something like that? > err: > fdput(f); > return ret; > } [...]
WARNING: multiple messages have this Message-ID (diff)
From: Jann Horn <jannh@google.com> To: Christian Brauner <christian@brauner.io> Cc: Andy Lutomirski <luto@kernel.org>, David Howells <dhowells@redhat.com>, "Serge E. Hallyn" <serge@hallyn.com>, Linux API <linux-api@vger.kernel.org>, kernel list <linux-kernel@vger.kernel.org>, Arnd Bergmann <arnd@arndb.de>, "Eric W. Biederman" <ebiederm@xmission.com>, Konstantin Khlebnikov <khlebnikov@yandex-team.ru>, Kees Cook <keescook@chromium.org>, Alexey Dobriyan <adobriyan@gmail.com>, Thomas Gleixner <tglx@linutronix.de>, Michael Kerrisk-manpages <mtk.manpages@gmail.com>, Jonathan Kowalski <bl0pbl33p@gmail.com>, "Dmitry V. Levin" <ldv@altlinux.org>, Andrew Morton <akpm@linux-foundation.org>, Oleg Nesterov <oleg@redhat.com>, Nagarathnam Muthusamy <nagarathnam.muthusamy@oracle.com>, Aleksa Sarai <cyphar@cyphar.com>, Al Viro <viro@zeniv.li> Subject: Re: [PATCH v2 4/5] signal: PIDFD_SIGNAL_TID threads via pidfds Date: Sat, 30 Mar 2019 02:06:34 +0100 [thread overview] Message-ID: <CAG48ez0=Q2CzgTGLiEU7F9B=gS-58VrpKz2XQ369cemo2FJdbQ@mail.gmail.com> (raw) In-Reply-To: <20190329155425.26059-5-christian@brauner.io> On Fri, Mar 29, 2019 at 4:54 PM Christian Brauner <christian@brauner.io> wrote: > With the addition of pidfd_open() it is possible for users to reference a > specific thread by doing: > > int pidfd = pidfd_open(<tid>, 0); > > This means we can extend pidfd_send_signal() to signal a specific thread. > As promised in the commit for pidfd_send_signal() [1] the extension is > based on a flag argument, i.e. the scope of the signal delivery is based on > the flag argument, not on the type of file descriptor. > To this end the flag PIDFD_SIGNAL_TID is added. With this change we now > cover most of the functionality of all the other signal sending functions > combined: [...] > diff --git a/include/uapi/linux/wait.h b/include/uapi/linux/wait.h > index d6c7c0701997..b72f0ef84fe5 100644 > --- a/include/uapi/linux/wait.h > +++ b/include/uapi/linux/wait.h [...] > +/* Flags to pass to pidfd_send_signal */ > +#define PIDFD_SIGNAL_TID 1 /* Send signal to specific thread */ nit: s/1/1U/; the flags argument is an `unsigned int` > #endif /* _UAPI_LINUX_WAIT_H */ > diff --git a/kernel/signal.c b/kernel/signal.c > index eb97d0cc6ef7..9f93da85b2b9 100644 > --- a/kernel/signal.c > +++ b/kernel/signal.c [...] > +static int pidfd_send_signal_specific(struct pid *pid, int sig, > + struct kernel_siginfo *info) > +{ > + struct task_struct *p; > + int error = -ESRCH; > + > + rcu_read_lock(); > + p = pid_task(pid, PIDTYPE_PID); > + if (p) > + error = __do_send_specific(p, sig, info); > + rcu_read_unlock(); > + > + return error; > +} > + > /** > - * sys_pidfd_send_signal - send a signal to a process through a task file > - * descriptor > + * sys_pidfd_send_signal - send a signal to a process through a pidfd > + > * @pidfd: the file descriptor of the process > * @sig: signal to be sent > * @info: the signal info > * @flags: future flags to be passed nit: comment is outdated, it isn't "future flags" anymore [...] > + * rt_tgsigqueueinfo(<tgid>, <tid>, <sig>, <uinfo>) > + * - pidfd_send_signal(<pidfd>, <sig>, <info>, PIDFD_SIGNAL_TID); > + * which is equivalent to > + * rt_tgsigqueueinfo(<tgid>, <tid>, <sig>, <uinfo>) > + * > * In order to extend the syscall to threads and process groups the @flags > * argument should be used. In essence, the @flags argument will determine > * what is signaled and not the file descriptor itself. Put in other words, nit: again, outdated comment about @flags [...] > @@ -3626,43 +3695,16 @@ SYSCALL_DEFINE4(pidfd_send_signal, int, pidfd, int, sig, > prepare_kill_siginfo(sig, &kinfo); > } > > - ret = kill_pid_info(sig, &kinfo, pid); > + if (flags & PIDFD_SIGNAL_TID) > + ret = pidfd_send_signal_specific(pid, sig, &kinfo); > + else > + ret = kill_pid_info(sig, &kinfo, pid); nit: maybe give pidfd_send_signal_specific() and kill_pid_info() the same signatures, since they perform similar operations with the same argument types? Something that was already kinda weird in the existing code, but is getting worse with TIDs is the handling of SI_USER with siginfo. Copying context lines from above here: if (info) { ret = copy_siginfo_from_user_any(&kinfo, info); if (unlikely(ret)) goto err; ret = -EINVAL; if (unlikely(sig != kinfo.si_signo)) goto err; if ((task_pid(current) != pid) && (kinfo.si_code >= 0 || kinfo.si_code == SI_TKILL)) { /* Only allow sending arbitrary signals to yourself. */ ret = -EPERM; if (kinfo.si_code != SI_USER) goto err; /* Turn this into a regular kill signal. */ prepare_kill_siginfo(sig, &kinfo); } } else { prepare_kill_siginfo(sig, &kinfo); } So for signals to PIDs, the rule is that if you send siginfo with SI_USER to yourself, the siginfo is preserved; otherwise the kernel silently clobbers it. That's already kind of weird - silent behavior difference depending on a security check. But now, for signals to threads, I think the result is going to be that signalling the thread group leader preserves information, and signalling any other thread clobbers it? If so, that seems bad. do_rt_sigqueueinfo() seems to have the same issue, from a glance - but there, at least the error case is just a -EPERM, not a silent behavior difference. Would it make sense to refuse sending siginfo with SI_USER to non-current? If you actually want to send a normal SI_USER signal, you can use info==NULL, right? That should create wrongness parity with do_rt_sigqueueinfo(). To improve things further, I guess you'd have to move the comparison against current into pidfd_send_signal_specific(), or move the task lookup out of it, or something like that? > err: > fdput(f); > return ret; > } [...]
next prev parent reply other threads:[~2019-03-30 1:07 UTC|newest] Thread overview: 158+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-03-29 15:54 [PATCH v2 0/5] pid: add pidfd_open() Christian Brauner 2019-03-29 15:54 ` [PATCH v2 1/5] Make anon_inodes unconditional Christian Brauner 2019-03-29 15:54 ` [PATCH v2 2/5] pid: add pidfd_open() Christian Brauner 2019-03-29 23:45 ` Jann Horn 2019-03-29 23:45 ` Jann Horn 2019-03-29 23:55 ` Christian Brauner 2019-03-29 23:55 ` Christian Brauner 2019-03-30 11:53 ` Jürg Billeter 2019-03-30 14:37 ` Christian Brauner 2019-03-30 14:51 ` Jonathan Kowalski 2019-03-30 14:51 ` Jonathan Kowalski 2019-03-29 15:54 ` [PATCH v2 3/5] signal: support pidfd_open() with pidfd_send_signal() Christian Brauner 2019-03-29 15:54 ` [PATCH v2 4/5] signal: PIDFD_SIGNAL_TID threads via pidfds Christian Brauner 2019-03-30 1:06 ` Jann Horn [this message] 2019-03-30 1:06 ` Jann Horn 2019-03-30 1:22 ` Christian Brauner 2019-03-30 1:22 ` Christian Brauner 2019-03-30 1:34 ` Christian Brauner 2019-03-30 1:34 ` Christian Brauner 2019-03-30 1:42 ` Christian Brauner 2019-03-30 1:42 ` Christian Brauner 2019-03-29 15:54 ` [PATCH v2 5/5] tests: add pidfd_open() tests Christian Brauner 2019-03-30 16:09 ` [PATCH v2 0/5] pid: add pidfd_open() Linus Torvalds 2019-03-30 16:09 ` Linus Torvalds 2019-03-30 16:11 ` Daniel Colascione 2019-03-30 16:11 ` Daniel Colascione 2019-03-30 16:16 ` Linus Torvalds 2019-03-30 16:16 ` Linus Torvalds 2019-03-30 16:18 ` Linus Torvalds 2019-03-30 16:18 ` Linus Torvalds 2019-03-31 1:07 ` Joel Fernandes 2019-03-31 1:07 ` Joel Fernandes 2019-03-31 2:34 ` Jann Horn 2019-03-31 2:34 ` Jann Horn 2019-03-31 4:08 ` Joel Fernandes 2019-03-31 4:08 ` Joel Fernandes 2019-03-31 4:46 ` Jann Horn 2019-03-31 4:46 ` Jann Horn 2019-03-31 14:52 ` Linus Torvalds 2019-03-31 14:52 ` Linus Torvalds 2019-03-31 15:05 ` Christian Brauner 2019-03-31 15:05 ` Christian Brauner 2019-03-31 15:21 ` Daniel Colascione 2019-03-31 15:21 ` Daniel Colascione 2019-03-31 15:33 ` Jonathan Kowalski 2019-03-31 15:33 ` Jonathan Kowalski 2019-03-30 16:19 ` Christian Brauner 2019-03-30 16:19 ` Christian Brauner 2019-03-30 16:24 ` Linus Torvalds 2019-03-30 16:24 ` Linus Torvalds 2019-03-30 16:34 ` Daniel Colascione 2019-03-30 16:34 ` Daniel Colascione 2019-03-30 16:38 ` Christian Brauner 2019-03-30 16:38 ` Christian Brauner 2019-03-30 17:04 ` Linus Torvalds 2019-03-30 17:04 ` Linus Torvalds 2019-03-30 17:12 ` Christian Brauner 2019-03-30 17:12 ` Christian Brauner 2019-03-30 17:24 ` Linus Torvalds 2019-03-30 17:24 ` Linus Torvalds 2019-03-30 17:37 ` Christian Brauner 2019-03-30 17:37 ` Christian Brauner 2019-03-30 17:50 ` Jonathan Kowalski 2019-03-30 17:50 ` Jonathan Kowalski 2019-03-30 17:52 ` Christian Brauner 2019-03-30 17:52 ` Christian Brauner 2019-03-30 17:59 ` Jonathan Kowalski 2019-03-30 17:59 ` Jonathan Kowalski 2019-03-30 18:02 ` Christian Brauner 2019-03-30 18:02 ` Christian Brauner 2019-03-30 18:00 ` Jann Horn 2019-03-30 18:00 ` Jann Horn 2019-03-31 20:09 ` Andy Lutomirski 2019-03-31 20:09 ` Andy Lutomirski 2019-03-31 21:03 ` Linus Torvalds 2019-03-31 21:03 ` Linus Torvalds 2019-03-31 21:10 ` Christian Brauner 2019-03-31 21:10 ` Christian Brauner 2019-03-31 21:17 ` Linus Torvalds 2019-03-31 21:17 ` Linus Torvalds 2019-03-31 22:03 ` Christian Brauner 2019-03-31 22:03 ` Christian Brauner 2019-03-31 22:16 ` Linus Torvalds 2019-03-31 22:16 ` Linus Torvalds 2019-03-31 22:33 ` Christian Brauner 2019-03-31 22:33 ` Christian Brauner 2019-04-01 0:52 ` Jann Horn 2019-04-01 0:52 ` Jann Horn 2019-04-01 8:47 ` Yann Droneaud 2019-04-01 8:47 ` Yann Droneaud 2019-04-01 10:03 ` Jonathan Kowalski 2019-04-01 10:03 ` Jonathan Kowalski 2019-03-31 23:40 ` Linus Torvalds 2019-03-31 23:40 ` Linus Torvalds 2019-04-01 0:09 ` Al Viro 2019-04-01 0:09 ` Al Viro 2019-04-01 0:18 ` Linus Torvalds 2019-04-01 0:18 ` Linus Torvalds 2019-04-01 0:21 ` Christian Brauner 2019-04-01 0:21 ` Christian Brauner 2019-04-01 6:37 ` Al Viro 2019-04-01 6:37 ` Al Viro 2019-04-01 6:41 ` Al Viro 2019-04-01 6:41 ` Al Viro 2019-03-31 22:03 ` Jonathan Kowalski 2019-03-31 22:03 ` Jonathan Kowalski 2019-04-01 2:13 ` Andy Lutomirski 2019-04-01 2:13 ` Andy Lutomirski 2019-04-01 11:40 ` Aleksa Sarai 2019-04-01 11:40 ` Aleksa Sarai 2019-04-01 15:36 ` Linus Torvalds 2019-04-01 15:36 ` Linus Torvalds 2019-04-01 15:47 ` Christian Brauner 2019-04-01 15:47 ` Christian Brauner 2019-04-01 15:55 ` Daniel Colascione 2019-04-01 15:55 ` Daniel Colascione 2019-04-01 16:01 ` Linus Torvalds 2019-04-01 16:01 ` Linus Torvalds 2019-04-01 16:13 ` Daniel Colascione 2019-04-01 16:13 ` Daniel Colascione 2019-04-01 19:42 ` Christian Brauner 2019-04-01 19:42 ` Christian Brauner 2019-04-01 21:30 ` Linus Torvalds 2019-04-01 21:30 ` Linus Torvalds 2019-04-01 21:58 ` Jonathan Kowalski 2019-04-01 21:58 ` Jonathan Kowalski 2019-04-01 22:13 ` Linus Torvalds 2019-04-01 22:13 ` Linus Torvalds 2019-04-01 22:34 ` Daniel Colascione 2019-04-01 22:34 ` Daniel Colascione 2019-04-01 16:07 ` Jonathan Kowalski 2019-04-01 16:07 ` Jonathan Kowalski 2019-04-01 16:15 ` Linus Torvalds 2019-04-01 16:15 ` Linus Torvalds 2019-04-01 16:27 ` Jonathan Kowalski 2019-04-01 16:27 ` Jonathan Kowalski 2019-04-01 16:21 ` Daniel Colascione 2019-04-01 16:21 ` Daniel Colascione 2019-04-01 16:29 ` Linus Torvalds 2019-04-01 16:29 ` Linus Torvalds 2019-04-01 16:45 ` Daniel Colascione 2019-04-01 16:45 ` Daniel Colascione 2019-04-01 17:00 ` David Laight 2019-04-01 17:00 ` David Laight 2019-04-01 17:32 ` Linus Torvalds 2019-04-01 17:32 ` Linus Torvalds 2019-04-02 11:03 ` Florian Weimer 2019-04-02 11:03 ` Florian Weimer 2019-04-01 16:10 ` Andy Lutomirski 2019-04-01 16:10 ` Andy Lutomirski 2019-04-01 12:04 ` Christian Brauner 2019-04-01 12:04 ` Christian Brauner 2019-04-01 13:43 ` Jann Horn 2019-04-01 13:43 ` Jann Horn 2019-03-31 21:19 ` Christian Brauner 2019-03-31 21:19 ` Christian Brauner 2019-03-30 16:37 ` Christian Brauner 2019-03-30 16:37 ` Christian Brauner
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='CAG48ez0=Q2CzgTGLiEU7F9B=gS-58VrpKz2XQ369cemo2FJdbQ@mail.gmail.com' \ --to=jannh@google.com \ --cc=adobriyan@gmail.com \ --cc=akpm@linux-foundation.org \ --cc=arnd@arndb.de \ --cc=bl0pbl33p@gmail.com \ --cc=christian@brauner.io \ --cc=cyphar@cyphar.com \ --cc=dancol@google.com \ --cc=dhowells@redhat.com \ --cc=ebiederm@xmission.com \ --cc=fweimer@redhat.com \ --cc=joel@joelfernandes.org \ --cc=keescook@chromium.org \ --cc=khlebnikov@yandex-team.ru \ --cc=ldv@altlinux.org \ --cc=linux-api@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=luto@kernel.org \ --cc=mtk.manpages@gmail.com \ --cc=nagarathnam.muthusamy@oracle.com \ --cc=oleg@redhat.com \ --cc=serge@hallyn.com \ --cc=tglx@linutronix.de \ --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: linkBe 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.