From: Tycho Andersen <tycho@tycho.ws>
To: Kees Cook <keescook@chromium.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
Thomas Gleixner <tglx@linutronix.de>,
Oleg Nesterov <oleg@redhat.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: siginfo pid not populated from ptrace?
Date: Thu, 29 Nov 2018 16:22:45 -0700 [thread overview]
Message-ID: <20181129232245.GC4676@cisco> (raw)
In-Reply-To: <CAGXu5jJv+TG8hovHi3Z5kTccz+Cx-keu=KZf032mCz2VRpc=Og@mail.gmail.com>
On Thu, Nov 29, 2018 at 01:17:01PM -0800, Kees Cook wrote:
> On Tue, Nov 27, 2018 at 8:44 PM Eric W. Biederman <ebiederm@xmission.com> wrote:
> >
> > Kees Cook <keescook@chromium.org> writes:
> >
> > > On Tue, Nov 27, 2018 at 4:38 PM, Kees Cook <keescook@chromium.org> wrote:
> > >> On Tue, Nov 27, 2018 at 3:21 PM, Tycho Andersen <tycho@tycho.ws> wrote:
> > >>> On Mon, Nov 12, 2018 at 12:24:43PM -0700, Tycho Andersen wrote:
> > >>>> On Mon, Nov 12, 2018 at 11:55:38AM -0700, Tycho Andersen wrote:
> > >>>> > I haven't manage to reproduce it on stock v4.20-rc2, unfortunately.
> > >>>>
> > >>>> Ok, now I have,
> > >>>>
> > >>>> seccomp_bpf.c:2736:global.syscall_restart:Expected getpid() (1493) == info._sifields._kill.si_pid (0)
> > >>>> global.syscall_restart: Test failed at step #22
> > >>>
> > >>> Seems like this is still happening on v4.20-rc4,
> > >>>
> > >>> [ RUN ] global.syscall_restart
> > >>> seccomp_bpf.c:2736:global.syscall_restart:Expected getpid() (1901) == info._sifields._kill.si_pid (0)
> > >>> global.syscall_restart: Test failed at step #22
> > >>
> > >> This fails every time for me -- is it still racey for you?
> > >>
> > >> I'm attempting a bisect, hoping it doesn't _become_ racey for me. ;)
> > >
> > > This bisect to here for me:
> > >
> > > commit f149b31557446aff9ca96d4be7e39cc266f6e7cc
> > > Author: Eric W. Biederman <ebiederm@xmission.com>
> > > Date: Mon Sep 3 09:50:36 2018 +0200
> > >
> > > signal: Never allocate siginfo for SIGKILL or SIGSTOP
> > >
> > > The SIGKILL and SIGSTOP signals are never delivered to userspace so
> > > queued siginfo for these signals can never be observed. Therefore
> > > remove the chance of failure by never even attempting to allocate
> > > siginfo in those cases.
> > >
> > > Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
> > > Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
> > >
> > > They are certainly visible via seccomp ;)
> >
> > Well SIGSTOP is visible via PTRACE_GETSIGINFO.
> >
> > I see what is happening now. Since we don't have queued siginfo
> > we generate some as:
> > /*
> > * Ok, it wasn't in the queue. This must be
> > * a fast-pathed signal or we must have been
> > * out of queue space. So zero out the info.
> > */
> > clear_siginfo(info);
> > info->si_signo = sig;
> > info->si_errno = 0;
> > info->si_code = SI_USER;
> > info->si_pid = 0;
> > info->si_uid = 0;
> >
> > Which allows last_signfo to be set,
> > so despite not really having any siginfo PTRACE_GET_SIGINFO
> > has something to return so does not return -EINVAL.
> >
> > Reconstructing my context that was part of removing SEND_SIG_FORCED
> > so this looks like it will take a little more than a revert to fix
> > this.
> >
> > This is definitely a change that is visible to user space. The logic in
> > my patch was definitely wrong with respect to SIGSTOP and
> > PTRACE_GETSIGINFO. Is there something in userspace that actually cares?
> > AKA is the idiom that the test seccomp_bpf.c is using something that
> > non-test code does?
>
> I think this would be needed by any ptracer that handled multiple
> threads. It needs to figure out which pid stopped. I think it's worth
> fixing, yes.
>
> > The change below should restore the old behavior. I am just wondering
> > if this is something we want to do. siginfo is allocated with
> > GFP_ATOMIC so if your machine is under memory pressure there is a real
> > chance the allocation can fail. Which would cause whatever is breaking
> > now to break less deterministically then.
>
> I think memory pressure that would block a 128 byte GFP_ATOMIC
> allocation would mean the system was about to seriously fall over.
> Given the user-facing behavior change and that an existing test was
> already checking for this means we need to fix it.
>
> > If we need to fix this do we need to make siginfo allocation more
> > reliable?
>
> I don't think so -- we'd already get a WARN() if allocation failed.
>
> > Eric
> >
> >
> > diff --git a/kernel/signal.c b/kernel/signal.c
> > index 4fd431ce4f91..5c34c55bfea4 100644
> > --- a/kernel/signal.c
> > +++ b/kernel/signal.c
> > @@ -1057,10 +1057,10 @@ static int __send_signal(int sig, struct kernel_siginfo *info, struct task_struc
> >
> > result = TRACE_SIGNAL_DELIVERED;
> > /*
> > - * Skip useless siginfo allocation for SIGKILL SIGSTOP,
> > + * Skip useless siginfo allocation for SIGKILL,
> > * and kernel threads.
> > */
> > - if (sig_kernel_only(sig) || (t->flags & PF_KTHREAD))
> > + if ((sig == SIGKILL) || (t->flags & PF_KTHREAD))
> > goto out_set;
> >
> > /*
> >
>
> This fixes it for me!
>
> Reported-by: Tycho Andersen <tycho@tycho.ws>
> Tested-by: Kees Cook <keescook@chromium.org>
> Fixes: f149b3155744 ("signal: Never allocate siginfo for SIGKILL or SIGSTOP")
Thanks guys, it works for me too.
Tested-by: Tycho Andersen <tycho@tycho.ws>
Tycho
next prev parent reply other threads:[~2018-11-29 23:22 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 [this message]
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
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=20181129232245.GC4676@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 \
/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).