linux-kernel - Re: SIGSTOP && ptrace (Was: ptrace(PTRACE_SYSCALL/CONT/DETACH, ..., SIGSTOP) does not work)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 23 Apr 2009 23:23:54 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Denys Vlasenko <vda.linux@...glemail.com>,
	linux-kernel@...r.kernel.org,
	Jan Kratochvil <jan.kratochvil@...hat.com>
Subject: Re: SIGSTOP && ptrace (Was: ptrace(PTRACE_SYSCALL/CONT/DETACH, ...,
	SIGSTOP) does not work)

> > IOW: strace does NOT want to see this signal reported back to strace -
> > it already saw that, what's the point in seeing it again?
> 
> As I said many times, the second report is not about the signal, it
> reports that the group-stop is completed.

Oleg is correct.  The "second" report, is not "WIFSTOPPED means a ptrace
stop".  It is "WIFSTOPPED means a job control stop".  This is not meant as
a notification to tracer, but a notification to parent.  In case of
PTRACE_ATTACH, this is "unnatural" because the tracer steals the parent's
notifications, but that's just the known crime against nature that is
ptrace semantics.

> I guess, you don't like the fact that finish_stop() always clear ->exit_code
> after wake up. This is why the next ptrace(PTRACE_SYSCALL, SIGSTOP) (called
> when the tracee sleeps in finish_stop) "loses" SIGSTOP.
> 
> I can't say if this really right or not, but I guess it is too late to
> change this behaviour. I may be wrong.

I agree it's unfortunate.  But TBH it's more unfortunate that PTRACE_CONT
et al are allowed here at all.  It's a job control stop, and if the world
were right then it would only be broken by SIGCONT.  But Oleg is right,
it's too late to change it now.  Them's the semantics.

> Perhaps, you should ask how strace can distinguish between "SIGSTOP
> recieved" and "group-stop completed". I am not 100% sure, but at first
> glance this looks possible.

It is, but it's easier than the hack you suggest.  PTRACE_GETSIGINFO only
works for a ptrace stop, not a job control stop.  If wait reported SIGSTOP,
PTRACE_GETSIGINFO will fail with EINVAL for a job control stop but will
succeed for a ptrace stop.

Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/