From: Tycho Andersen <tycho@tycho.ws>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
Kees Cook <keescook@chromium.org>,
Thomas Gleixner <tglx@linutronix.de>,
Oleg Nesterov <oleg@redhat.com>,
Linux List Kernel Mailing <linux-kernel@vger.kernel.org>
Subject: Re: siginfo pid not populated from ptrace?
Date: Thu, 6 Dec 2018 12:20:59 -0700 [thread overview]
Message-ID: <20181206192059.GD10086@cisco> (raw)
In-Reply-To: <CAHk-=wjTzjOqEhWJskx7ToHL2d1KUxsNOZ2V0=v_R6VJYtOm7Q@mail.gmail.com>
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 <ebiederm@xmission.com> 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.
Tycho
From 3bcaadd56ebb532ab4d481556fcc0826d65efc43 Mon Sep 17 00:00:00 2001
From: Tycho Andersen <tycho@tycho.ws>
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/87zhtthkuy.fsf@xmission.com/T/#u
so let's allocate a siginfo for SIGSTOP when a task is traced.
Signed-off-by: Tycho Andersen <tycho@tycho.ws>
---
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;
/*
--
2.19.1
next prev parent reply other threads:[~2018-12-06 19:21 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-12 17:11 siginfo pid not populated from ptrace? Tycho Andersen
2018-11-12 18:30 ` Eric W. Biederman
2018-11-12 18:55 ` Tycho Andersen
2018-11-12 19:22 ` Eric W. Biederman
2018-11-12 19:24 ` Tycho Andersen
2018-11-27 23:21 ` Tycho Andersen
2018-11-28 0:38 ` Kees Cook
2018-11-28 1:17 ` Kees Cook
2018-11-28 4:44 ` Eric W. Biederman
2018-11-29 21:17 ` Kees Cook
2018-11-29 23:22 ` Tycho Andersen
2018-12-01 15:04 ` Eric W. Biederman
2018-12-06 1:00 ` Kees Cook
2018-12-06 14:40 ` Eric W. Biederman
2018-12-06 18:48 ` Linus Torvalds
2018-12-06 19:20 ` Tycho Andersen [this message]
2018-12-06 21:11 ` Eric W. Biederman
2018-12-06 21:34 ` Kees Cook
2018-12-06 22:43 ` Eric W. Biederman
2018-12-06 22:55 ` Kees Cook
2018-12-10 15:37 ` Oleg Nesterov
2018-12-10 15:44 ` Tycho Andersen
2018-12-10 17:36 ` Eric W. Biederman
2018-12-10 14:57 ` Oleg Nesterov
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=20181206192059.GD10086@cisco \
--to=tycho@tycho.ws \
--cc=ebiederm@xmission.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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: link
Be 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.