From: Enke Chen <enkechen@cisco.com> To: Jann Horn <jannh@google.com> Cc: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, "H . Peter Anvin" <hpa@zytor.com>, the arch/x86 maintainers <x86@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Arnd Bergmann <arnd@arndb.de>, "Eric W. Biederman" <ebiederm@xmission.com>, Khalid Aziz <khalid.aziz@oracle.com>, Kate Stewart <kstewart@linuxfoundation.org>, deller@gmx.de, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Al Viro <viro@zeniv.linux.org.uk>, Andrew Morton <akpm@linux-foundation.org>, christian@brauner.io, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will.deacon@arm.com>, Dave.Martin@arm.com, mchehab+samsung@kernel.org, Michal Hocko <mhocko@kernel.org>, Rik van Riel <riel@surriel.com>, "Kirill A . Shutemov" <kirill.sh> Subject: Re: [PATCH] kernel/signal: Signal-based pre-coredump notification Date: Mon, 15 Oct 2018 11:36:19 -0700 [thread overview] Message-ID: <c5a09a04-b4f2-876b-af83-30f7e527497e@cisco.com> (raw) In-Reply-To: <CAG48ez2ZPhnxudqgU7nC2ORvLnS0Ja-qhLSE5WAY361jst7XNw@mail.gmail.com> Hi, Jann: Thanks a lot for you detailed review. Please see my replied/comments inline. On 10/13/18 11:27 AM, Jann Horn wrote: > On Sat, Oct 13, 2018 at 2:33 AM Enke Chen <enkechen@cisco.com> wrote: >> For simplicity and consistency, this patch provides an implementation >> for signal-based fault notification prior to the coredump of a child >> process. A new prctl command, PR_SET_PREDUMP_SIG, is defined that can >> be used by an application to express its interest and to specify the >> signal (SIGCHLD or SIGUSR1 or SIGUSR2) for such a notification. A new >> signal code (si_code), CLD_PREDUMP, is also defined for SIGCHLD. > > Your suggested API looks vaguely similar to PR_SET_PDEATHSIG, but with > some important differences: > > - You don't reset the signal on setuid execution. > - You permit setting this not just on the current process, but also on others. > > For both of these: Are these differences actually necessary, and if > so, can you provide a specific rationale? From a security perspective, > I would very much prefer it if this API had semantics closer to > PR_SET_PDEATHSIG. Regarding setting on others, I started with setting for self. But there is a requirement for supporting the feature for a process manager written in bash script. That's the reason for allowing the setting on others. Given the feedback from you and others, I agree that it would be simpler and more secure to remove the setting on others. We can submit a patch for bash to support the setting natively. Regarding the impact of "setuid", this property "PR_SET_PREDUMP_SIG" has to do with the application/process whether the signal handler is set for receiving such a notification. If it is set, the "uid" should not matter. > > [...] >> diff --git a/kernel/signal.c b/kernel/signal.c >> index 312b43e..eb4a483 100644 >> --- a/kernel/signal.c >> +++ b/kernel/signal.c >> @@ -2337,6 +2337,44 @@ static int ptrace_signal(int signr, kernel_siginfo_t *info) >> return signr; >> } >> >> +/* >> + * Let the parent, if so desired, know about the imminent death of a child >> + * prior to its coredump. >> + * >> + * Locking logic is similar to do_notify_parent_cldstop(). >> + */ >> +static void do_notify_parent_predump(struct task_struct *tsk) >> +{ >> + struct sighand_struct *sighand; >> + struct task_struct *parent; >> + struct kernel_siginfo info; >> + unsigned long flags; >> + int sig; >> + >> + parent = tsk->real_parent; >> + sig = parent->predump_signal; >> + >> + /* Check again with "tasklist_lock" locked by the caller */ >> + if (!valid_predump_signal(sig)) >> + return; >> + >> + clear_siginfo(&info); >> + info.si_signo = sig; >> + if (sig == SIGCHLD) >> + info.si_code = CLD_PREDUMP; >> + >> + rcu_read_lock(); >> + info.si_pid = task_pid_nr_ns(tsk, task_active_pid_ns(parent)); >> + info.si_uid = from_kuid_munged(task_cred_xxx(parent, user_ns), >> + task_uid(tsk)); > > You're sending a signal from the current namespaces, but with IDs that > have been mapped into the parent's namespaces? That looks wrong to me. I am following the example "do_notify_parent_cldstop()" called in the same routine "get_signal()". If there is a better way, sure I will use it. > >> + rcu_read_unlock(); >> + >> + sighand = parent->sighand; >> + spin_lock_irqsave(&sighand->siglock, flags); >> + __group_send_sig_info(sig, &info, parent); >> + spin_unlock_irqrestore(&sighand->siglock, flags); >> +} >> + >> bool get_signal(struct ksignal *ksig) >> { >> struct sighand_struct *sighand = current->sighand; >> @@ -2497,6 +2535,19 @@ bool get_signal(struct ksignal *ksig) >> current->flags |= PF_SIGNALED; >> >> if (sig_kernel_coredump(signr)) { >> + /* >> + * Notify the parent prior to the coredump if the >> + * parent is interested in such a notificaiton. >> + */ >> + int p_sig = current->real_parent->predump_signal; > > current->real_parent is an __rcu member. I think if you run the sparse > checker against this patch, it's going to complain. Are you allowed to > access current->real_parent in this context? Let me check, and get back to you on this one. > >> + if (valid_predump_signal(p_sig)) { >> + read_lock(&tasklist_lock); >> + do_notify_parent_predump(current); >> + read_unlock(&tasklist_lock); >> + cond_resched(); >> + } >> + >> if (print_fatal_signals) >> print_fatal_signal(ksig->info.si_signo); >> proc_coredump_connector(current); >> diff --git a/kernel/sys.c b/kernel/sys.c >> index 123bd73..43eb250d 100644 >> --- a/kernel/sys.c >> +++ b/kernel/sys.c >> @@ -2258,6 +2258,76 @@ int __weak arch_prctl_spec_ctrl_set(struct task_struct *t, unsigned long which, >> return -EINVAL; >> } >> >> +static int prctl_get_predump_signal(struct task_struct *tsk, pid_t pid, >> + int __user *addr) >> +{ >> + struct task_struct *p; >> + int error; >> + >> + /* For the current task, the common case */ >> + if (pid == 0) { >> + put_user(tsk->predump_signal, addr); >> + return 0; >> + } >> + >> + error = -ESRCH; >> + rcu_read_lock(); >> + p = find_task_by_vpid(pid); >> + if (p) { >> + error = 0; >> + put_user(p->predump_signal, addr); > > This is wrong. You can't call put_user() while you're in an RCU > read-side critical section. > > As below, I would like it if you could just get rid of this branch, > and restrict this prctl to operating on the current process. My bad. The code will be removed. > >> + } >> + rcu_read_unlock(); >> + return error; >> +} >> + >> +/* >> + * Returns true if current's euid is same as p's uid or euid, >> + * or has CAP_SYS_ADMIN. >> + * >> + * Called with rcu_read_lock, creds are safe. >> + * >> + * Adapted from set_one_prio_perm(). >> + */ >> +static bool set_predump_signal_perm(struct task_struct *p) >> +{ >> + const struct cred *cred = current_cred(), *pcred = __task_cred(p); >> + >> + return uid_eq(pcred->uid, cred->euid) || >> + uid_eq(pcred->euid, cred->euid) || >> + capable(CAP_SYS_ADMIN); >> +} > > This permission check permits fiddling with other processes in > scenarios where kill() wouldn't let you send signals (specifically, if > you control the EUID of the target task). That worries me. Also, > kill() is subject to LSM checks (see check_kill_permission()), but > this interface isn't. I would really prefer it if you could amend this > so that you can only operate on the current task, and get rid of this > permission check. It is gone. > > [...] >> SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3, >> unsigned long, arg4, unsigned long, arg5) >> { >> @@ -2476,6 +2546,13 @@ int __weak arch_prctl_spec_ctrl_set(struct task_struct *t, unsigned long which, >> return -EINVAL; >> error = arch_prctl_spec_ctrl_set(me, arg2, arg3); >> break; >> + case PR_SET_PREDUMP_SIG: >> + error = prctl_set_predump_signal(me, (pid_t)arg2, (int)arg3); >> + break; >> + case PR_GET_PREDUMP_SIG: >> + error = prctl_get_predump_signal(me, (pid_t)arg2, >> + (int __user *)arg3); >> + break; > > New prctl() calls should check that the unused arguments are zero, in > order to make it possible to safely add more flags in the future. Will do. Thanks again. -- Enke
WARNING: multiple messages have this Message-ID (diff)
From: Enke Chen <enkechen@cisco.com> To: Jann Horn <jannh@google.com> Cc: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, "H . Peter Anvin" <hpa@zytor.com>, the arch/x86 maintainers <x86@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Arnd Bergmann <arnd@arndb.de>, "Eric W. Biederman" <ebiederm@xmission.com>, Khalid Aziz <khalid.aziz@oracle.com>, Kate Stewart <kstewart@linuxfoundation.org>, deller@gmx.de, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Al Viro <viro@zeniv.linux.org.uk>, Andrew Morton <akpm@linux-foundation.org>, christian@brauner.io, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will.deacon@arm.com>, Dave.Martin@arm.com, mchehab+samsung@kernel.org, Michal Hocko <mhocko@kernel.org>, Rik van Riel <riel@surriel.com>, "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>, guro@fb.com, marcos.souza.org@gmail.com, Oleg Nesterov <oleg@redhat.com>, linux@dominikbrodowski.net, Cyrill Gorcunov <gorcunov@openvz.org>, yang.shi@linux.alibaba.com, Kees Cook <keescook@chromium.org>, kernel list <linux-kernel@vger.kernel.org>, linux-arch <linux-arch@vger.kernel.org>, kamensky@cisco.com, xe-linux-external@cisco.com, sstrogin@cisco.com, Enke Chen <enkechen@cisco.com> Subject: Re: [PATCH] kernel/signal: Signal-based pre-coredump notification Date: Mon, 15 Oct 2018 11:36:19 -0700 [thread overview] Message-ID: <c5a09a04-b4f2-876b-af83-30f7e527497e@cisco.com> (raw) Message-ID: <20181015183619.DbK2i4nEVYeR7yv7yFf0ELLYd1eQAOzn02wMGyQbrug@z> (raw) In-Reply-To: <CAG48ez2ZPhnxudqgU7nC2ORvLnS0Ja-qhLSE5WAY361jst7XNw@mail.gmail.com> Hi, Jann: Thanks a lot for you detailed review. Please see my replied/comments inline. On 10/13/18 11:27 AM, Jann Horn wrote: > On Sat, Oct 13, 2018 at 2:33 AM Enke Chen <enkechen@cisco.com> wrote: >> For simplicity and consistency, this patch provides an implementation >> for signal-based fault notification prior to the coredump of a child >> process. A new prctl command, PR_SET_PREDUMP_SIG, is defined that can >> be used by an application to express its interest and to specify the >> signal (SIGCHLD or SIGUSR1 or SIGUSR2) for such a notification. A new >> signal code (si_code), CLD_PREDUMP, is also defined for SIGCHLD. > > Your suggested API looks vaguely similar to PR_SET_PDEATHSIG, but with > some important differences: > > - You don't reset the signal on setuid execution. > - You permit setting this not just on the current process, but also on others. > > For both of these: Are these differences actually necessary, and if > so, can you provide a specific rationale? From a security perspective, > I would very much prefer it if this API had semantics closer to > PR_SET_PDEATHSIG. Regarding setting on others, I started with setting for self. But there is a requirement for supporting the feature for a process manager written in bash script. That's the reason for allowing the setting on others. Given the feedback from you and others, I agree that it would be simpler and more secure to remove the setting on others. We can submit a patch for bash to support the setting natively. Regarding the impact of "setuid", this property "PR_SET_PREDUMP_SIG" has to do with the application/process whether the signal handler is set for receiving such a notification. If it is set, the "uid" should not matter. > > [...] >> diff --git a/kernel/signal.c b/kernel/signal.c >> index 312b43e..eb4a483 100644 >> --- a/kernel/signal.c >> +++ b/kernel/signal.c >> @@ -2337,6 +2337,44 @@ static int ptrace_signal(int signr, kernel_siginfo_t *info) >> return signr; >> } >> >> +/* >> + * Let the parent, if so desired, know about the imminent death of a child >> + * prior to its coredump. >> + * >> + * Locking logic is similar to do_notify_parent_cldstop(). >> + */ >> +static void do_notify_parent_predump(struct task_struct *tsk) >> +{ >> + struct sighand_struct *sighand; >> + struct task_struct *parent; >> + struct kernel_siginfo info; >> + unsigned long flags; >> + int sig; >> + >> + parent = tsk->real_parent; >> + sig = parent->predump_signal; >> + >> + /* Check again with "tasklist_lock" locked by the caller */ >> + if (!valid_predump_signal(sig)) >> + return; >> + >> + clear_siginfo(&info); >> + info.si_signo = sig; >> + if (sig == SIGCHLD) >> + info.si_code = CLD_PREDUMP; >> + >> + rcu_read_lock(); >> + info.si_pid = task_pid_nr_ns(tsk, task_active_pid_ns(parent)); >> + info.si_uid = from_kuid_munged(task_cred_xxx(parent, user_ns), >> + task_uid(tsk)); > > You're sending a signal from the current namespaces, but with IDs that > have been mapped into the parent's namespaces? That looks wrong to me. I am following the example "do_notify_parent_cldstop()" called in the same routine "get_signal()". If there is a better way, sure I will use it. > >> + rcu_read_unlock(); >> + >> + sighand = parent->sighand; >> + spin_lock_irqsave(&sighand->siglock, flags); >> + __group_send_sig_info(sig, &info, parent); >> + spin_unlock_irqrestore(&sighand->siglock, flags); >> +} >> + >> bool get_signal(struct ksignal *ksig) >> { >> struct sighand_struct *sighand = current->sighand; >> @@ -2497,6 +2535,19 @@ bool get_signal(struct ksignal *ksig) >> current->flags |= PF_SIGNALED; >> >> if (sig_kernel_coredump(signr)) { >> + /* >> + * Notify the parent prior to the coredump if the >> + * parent is interested in such a notificaiton. >> + */ >> + int p_sig = current->real_parent->predump_signal; > > current->real_parent is an __rcu member. I think if you run the sparse > checker against this patch, it's going to complain. Are you allowed to > access current->real_parent in this context? Let me check, and get back to you on this one. > >> + if (valid_predump_signal(p_sig)) { >> + read_lock(&tasklist_lock); >> + do_notify_parent_predump(current); >> + read_unlock(&tasklist_lock); >> + cond_resched(); >> + } >> + >> if (print_fatal_signals) >> print_fatal_signal(ksig->info.si_signo); >> proc_coredump_connector(current); >> diff --git a/kernel/sys.c b/kernel/sys.c >> index 123bd73..43eb250d 100644 >> --- a/kernel/sys.c >> +++ b/kernel/sys.c >> @@ -2258,6 +2258,76 @@ int __weak arch_prctl_spec_ctrl_set(struct task_struct *t, unsigned long which, >> return -EINVAL; >> } >> >> +static int prctl_get_predump_signal(struct task_struct *tsk, pid_t pid, >> + int __user *addr) >> +{ >> + struct task_struct *p; >> + int error; >> + >> + /* For the current task, the common case */ >> + if (pid == 0) { >> + put_user(tsk->predump_signal, addr); >> + return 0; >> + } >> + >> + error = -ESRCH; >> + rcu_read_lock(); >> + p = find_task_by_vpid(pid); >> + if (p) { >> + error = 0; >> + put_user(p->predump_signal, addr); > > This is wrong. You can't call put_user() while you're in an RCU > read-side critical section. > > As below, I would like it if you could just get rid of this branch, > and restrict this prctl to operating on the current process. My bad. The code will be removed. > >> + } >> + rcu_read_unlock(); >> + return error; >> +} >> + >> +/* >> + * Returns true if current's euid is same as p's uid or euid, >> + * or has CAP_SYS_ADMIN. >> + * >> + * Called with rcu_read_lock, creds are safe. >> + * >> + * Adapted from set_one_prio_perm(). >> + */ >> +static bool set_predump_signal_perm(struct task_struct *p) >> +{ >> + const struct cred *cred = current_cred(), *pcred = __task_cred(p); >> + >> + return uid_eq(pcred->uid, cred->euid) || >> + uid_eq(pcred->euid, cred->euid) || >> + capable(CAP_SYS_ADMIN); >> +} > > This permission check permits fiddling with other processes in > scenarios where kill() wouldn't let you send signals (specifically, if > you control the EUID of the target task). That worries me. Also, > kill() is subject to LSM checks (see check_kill_permission()), but > this interface isn't. I would really prefer it if you could amend this > so that you can only operate on the current task, and get rid of this > permission check. It is gone. > > [...] >> SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3, >> unsigned long, arg4, unsigned long, arg5) >> { >> @@ -2476,6 +2546,13 @@ int __weak arch_prctl_spec_ctrl_set(struct task_struct *t, unsigned long which, >> return -EINVAL; >> error = arch_prctl_spec_ctrl_set(me, arg2, arg3); >> break; >> + case PR_SET_PREDUMP_SIG: >> + error = prctl_set_predump_signal(me, (pid_t)arg2, (int)arg3); >> + break; >> + case PR_GET_PREDUMP_SIG: >> + error = prctl_get_predump_signal(me, (pid_t)arg2, >> + (int __user *)arg3); >> + break; > > New prctl() calls should check that the unused arguments are zero, in > order to make it possible to safely add more flags in the future. Will do. Thanks again. -- Enke
next prev parent reply other threads:[~2018-10-15 18:36 UTC|newest] Thread overview: 140+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-13 0:33 [PATCH] kernel/signal: Signal-based pre-coredump notification Enke Chen 2018-10-13 0:33 ` Enke Chen 2018-10-13 6:40 ` Greg Kroah-Hartman 2018-10-13 6:40 ` Greg Kroah-Hartman 2018-10-15 18:16 ` Enke Chen 2018-10-15 18:16 ` Enke Chen 2018-10-15 18:43 ` Greg Kroah-Hartman 2018-10-15 18:43 ` Greg Kroah-Hartman 2018-10-15 18:49 ` Enke Chen 2018-10-15 18:49 ` Enke Chen 2018-10-15 18:58 ` Greg Kroah-Hartman 2018-10-15 18:58 ` Greg Kroah-Hartman 2018-10-13 10:44 ` Christian Brauner 2018-10-13 10:44 ` Christian Brauner 2018-10-15 18:39 ` Enke Chen 2018-10-15 18:39 ` Enke Chen 2018-10-13 18:27 ` Jann Horn 2018-10-13 18:27 ` Jann Horn 2018-10-15 18:36 ` Enke Chen [this message] 2018-10-15 18:36 ` Enke Chen 2018-10-15 18:54 ` Jann Horn 2018-10-15 18:54 ` Jann Horn 2018-10-15 19:23 ` Enke Chen 2018-10-15 19:23 ` Enke Chen 2018-10-19 23:01 ` Enke Chen 2018-10-19 23:01 ` Enke Chen 2018-10-22 15:40 ` Jann Horn 2018-10-22 15:40 ` Jann Horn 2018-10-22 20:48 ` Enke Chen 2018-10-22 20:48 ` Enke Chen 2018-10-15 12:05 ` Oleg Nesterov 2018-10-15 12:05 ` Oleg Nesterov 2018-10-15 18:54 ` Enke Chen 2018-10-15 18:54 ` Enke Chen 2018-10-15 19:17 ` Enke Chen 2018-10-15 19:17 ` Enke Chen 2018-10-15 19:26 ` Enke Chen 2018-10-15 19:26 ` Enke Chen 2018-10-16 14:14 ` Oleg Nesterov 2018-10-16 14:14 ` Oleg Nesterov 2018-10-16 15:09 ` Eric W. Biederman 2018-10-16 15:09 ` Eric W. Biederman 2018-10-17 0:39 ` Enke Chen 2018-10-17 0:39 ` Enke Chen 2018-10-15 21:21 ` Alan Cox 2018-10-15 21:21 ` Alan Cox 2018-10-15 21:31 ` Enke Chen 2018-10-15 21:31 ` Enke Chen 2018-10-15 23:28 ` Eric W. Biederman 2018-10-15 23:28 ` Eric W. Biederman 2018-10-16 0:33 ` valdis.kletnieks 2018-10-16 0:33 ` valdis.kletnieks 2018-10-16 0:54 ` Enke Chen 2018-10-16 0:54 ` Enke Chen 2018-10-16 15:26 ` Eric W. Biederman 2018-10-16 15:26 ` Eric W. Biederman 2018-10-22 21:09 ` [PATCH v2] " Enke Chen 2018-10-22 21:09 ` Enke Chen 2018-10-23 9:23 ` Oleg Nesterov 2018-10-23 9:23 ` Oleg Nesterov 2018-10-23 19:43 ` Enke Chen 2018-10-23 19:43 ` Enke Chen 2018-10-23 21:40 ` Enke Chen 2018-10-23 21:40 ` Enke Chen 2018-10-24 13:52 ` Oleg Nesterov 2018-10-24 13:52 ` Oleg Nesterov 2018-10-24 21:56 ` Enke Chen 2018-10-24 21:56 ` Enke Chen 2018-10-24 5:39 ` [PATCH v3] " Enke Chen 2018-10-24 5:39 ` Enke Chen 2018-10-24 14:02 ` Oleg Nesterov 2018-10-24 14:02 ` Oleg Nesterov 2018-10-24 22:02 ` Enke Chen 2018-10-24 22:02 ` Enke Chen 2018-10-25 22:56 ` [PATCH v4] " Enke Chen 2018-10-25 22:56 ` Enke Chen 2018-10-26 8:28 ` Oleg Nesterov 2018-10-26 8:28 ` Oleg Nesterov 2018-10-26 22:23 ` Enke Chen 2018-10-26 22:23 ` Enke Chen 2018-10-29 11:18 ` Oleg Nesterov 2018-10-29 11:18 ` Oleg Nesterov 2018-10-29 21:08 ` Enke Chen 2018-10-29 21:08 ` Enke Chen 2018-10-29 22:31 ` [PATCH v5] " Enke Chen 2018-10-29 22:31 ` Enke Chen 2018-10-30 16:46 ` Oleg Nesterov 2018-10-30 16:46 ` Oleg Nesterov 2018-10-31 0:25 ` Enke Chen 2018-10-31 0:25 ` Enke Chen 2018-11-22 0:37 ` Andrew Morton 2018-11-22 0:37 ` Andrew Morton 2018-11-22 1:09 ` Enke Chen 2018-11-22 1:09 ` Enke Chen 2018-11-22 1:18 ` Enke Chen 2018-11-22 1:18 ` Enke Chen 2018-11-22 1:33 ` Andrew Morton 2018-11-22 1:33 ` Andrew Morton 2018-11-22 4:57 ` Enke Chen 2018-11-22 4:57 ` Enke Chen 2018-11-12 23:22 ` Enke Chen 2018-11-12 23:22 ` Enke Chen 2018-11-27 22:54 ` [PATCH v5 1/2] " Enke Chen 2018-11-27 22:54 ` Enke Chen 2018-11-28 15:19 ` Dave Martin 2018-11-28 15:19 ` Dave Martin 2018-11-29 0:15 ` Enke Chen 2018-11-29 0:15 ` Enke Chen 2018-11-29 11:55 ` Dave Martin 2018-11-29 11:55 ` Dave Martin 2018-11-30 0:27 ` Enke Chen 2018-11-30 0:27 ` Enke Chen 2018-11-30 12:03 ` Oleg Nesterov 2018-11-30 12:03 ` Oleg Nesterov 2018-12-05 6:47 ` Jann Horn 2018-12-05 6:47 ` Jann Horn 2018-12-04 22:37 ` Andrew Morton 2018-12-04 22:37 ` Andrew Morton 2018-12-06 17:29 ` Oleg Nesterov 2018-12-06 17:29 ` Oleg Nesterov 2018-10-25 22:56 ` [PATCH] selftests/prctl: selftest for pre-coredump signal notification Enke Chen 2018-10-25 22:56 ` Enke Chen 2018-11-27 22:54 ` [PATCH v5 2/2] " Enke Chen 2018-11-27 22:54 ` Enke Chen 2018-10-24 13:29 ` [PATCH v2] kernel/signal: Signal-based pre-coredump notification Eric W. Biederman 2018-10-24 13:29 ` Eric W. Biederman 2018-10-24 23:50 ` Enke Chen 2018-10-24 23:50 ` Enke Chen 2018-10-25 12:23 ` Eric W. Biederman 2018-10-25 12:23 ` Eric W. Biederman 2018-10-25 20:45 ` Enke Chen 2018-10-25 20:45 ` Enke Chen 2018-10-25 21:24 ` Enke Chen 2018-10-25 21:24 ` Enke Chen 2018-10-25 21:56 ` Enke Chen 2018-10-25 21:56 ` Enke Chen 2018-10-25 13:45 ` Jann Horn 2018-10-25 13:45 ` Jann Horn 2018-10-25 20:21 ` Eric W. Biederman 2018-10-25 20:21 ` Eric W. Biederman
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=c5a09a04-b4f2-876b-af83-30f7e527497e@cisco.com \ --to=enkechen@cisco.com \ --cc=Dave.Martin@arm.com \ --cc=akpm@linux-foundation.org \ --cc=arnd@arndb.de \ --cc=bp@alien8.de \ --cc=catalin.marinas@arm.com \ --cc=christian@brauner.io \ --cc=deller@gmx.de \ --cc=ebiederm@xmission.com \ --cc=gregkh@linuxfoundation.org \ --cc=hpa@zytor.com \ --cc=jannh@google.com \ --cc=khalid.aziz@oracle.com \ --cc=kstewart@linuxfoundation.org \ --cc=mchehab+samsung@kernel.org \ --cc=mhocko@kernel.org \ --cc=mingo@redhat.com \ --cc=peterz@infradead.org \ --cc=riel@surriel.com \ --cc=tglx@linutronix.de \ --cc=viro@zeniv.linux.org.uk \ --cc=will.deacon@arm.com \ --cc=x86@kernel.org \ /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 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).