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 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).