On Thu, Dec 6, 2018 at 1:11 PM Eric W. Biederman <[email protected]> wrote: > > Tycho Andersen <[email protected]> writes: > > > On Thu, Dec 06, 2018 at 10:48:39AM -0800, Linus Torvalds wrote: > >> On Thu, Dec 6, 2018 at 6:40 AM Eric W. Biederman <[email protected]> > >> wrote: > >> > > >> > We have in the past had ptrace users that weren't just about debugging > >> > so I don't know that it is fair to just dismiss it as debugging > >> > infrastructure. > >> > >> Absolutely. > >> > >> Some uses are more than just debug. People occasionally use ptrace > >> because it's the only way to do what they want, so you'll find people > >> who do it for sandboxing, for example. It's not necessarily designed > >> for that, or particularly fast or well-suited for it, but I've > >> definitely seen it used that way. > >> > >> So I don't think the behavioral test breakage like this is necessarily > >> a huge deal, and until some "real use" actually shows that it cares it > >> might be something we dismiss as "just test", but it very much has the > >> potential to hit real uses. > >> > >> The fact that a behavioral test broke is definitely interesting. > >> > >> And maybe some of the siginfo allocations could depend on whether the > >> signal is actually ever caught or not. > >> > >> For example, a terminal signal (or one that is ignored) might not need > >> siginfo. But if the process is ptraced, maybe that terminal signal > >> isn't actually terminal? So we might have situations where we want to > >> simply check "is the signal target being ptraced".. > > > > Yes, something like this, I suppose? It works for me. > > The challenge is that we could be delivering this to a zombie signal > group leader. At which point we won't deliver it to the target task. > > Sigh it is probably time that I dig in and figure out how to avoid that > case which we need to fix anyway because we can get the permission > checks wrong for multi-threaded processes that call setuid and friends. > > Once that is sorted your small change will at least be safe. > > Eric > > > From 3bcaadd56ebb532ab4d481556fcc0826d65efc43 Mon Sep 17 00:00:00 2001 > > From: Tycho Andersen <[email protected]> > > Date: Thu, 6 Dec 2018 12:15:22 -0700 > > Subject: [PATCH] signal: allocate siginfo when a traced task gets SIGSTOP > > > > Tracers can view SIGSTOP: > > > > https://lore.kernel.org/lkml/[email protected]/T/#u > > > > so let's allocate a siginfo for SIGSTOP when a task is traced. > > > > Signed-off-by: Tycho Andersen <[email protected]> > > --- > > kernel/signal.c | 9 ++++++--- > > 1 file changed, 6 insertions(+), 3 deletions(-) > > > > diff --git a/kernel/signal.c b/kernel/signal.c > > index 9a32bc2088c9..ab4ba00119f4 100644 > > --- a/kernel/signal.c > > +++ b/kernel/signal.c > > @@ -1056,11 +1056,14 @@ static int __send_signal(int sig, struct > > kernel_siginfo *info, struct task_struc > > goto ret; > > > > result = TRACE_SIGNAL_DELIVERED; > > + > > /* > > - * Skip useless siginfo allocation for SIGKILL SIGSTOP, > > - * and kernel threads. > > + * Skip useless siginfo allocation for SIGKILL and kernel threads. > > + * SIGSTOP is visible to tracers, so only skip allocation when the > > task > > + * is not traced. > > */ > > - if (sig_kernel_only(sig) || (t->flags & PF_KTHREAD)) > > + if ((sig == SIGKILL) || (!task_is_traced(t) && sig == SIGSTOP) || > > + (t->flags & PF_KTHREAD)) > > goto out_set; > > > > /*
What should we do for v4.20? I need to have the selftests actually passing. :) -- Kees Cook
