linux-kernel - Re: PTRACE_SEIZE should not stop [Re: [PATCH 02/11] ptrace: implement PTRACE

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]

Message-ID: <20110516134510.GA23665@htj.dyndns.org>
Date:	Mon, 16 May 2011 15:45:10 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Jan Kratochvil <jan.kratochvil@...hat.com>
Cc:	oleg@...hat.com, vda.linux@...glemail.com,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, indan@....nu
Subject: Re: PTRACE_SEIZE should not stop  [Re: [PATCH 02/11] ptrace:
 implement PTRACE_SEIZE]

Hello, Jan.

On Mon, May 16, 2011 at 03:21:23PM +0200, Jan Kratochvil wrote:
> Currently that waitpid will report SIGUSR1 first and then the INTERRUPT trap.

Yes, it would.

> I suggest - if possible - that tracer will get that INTERRUPT trap first.
> 
> But you made the optimization that the INTERRUPT gets suppressed in such case.
> Which improves performance for the cost of more complicated debuggers.

INTERRUPT is suppressed if group stop is pending not signal.  That was
more about duplicity between INTERRUPT trap and group stop, which made
the whole thing uglier.  I merged the two together so there's no such
distinction anymore.

> I guess after PTRACE_SEIZE if the first signal/event is not INTERRUPT there
> will not be any INTERRUPT later, as you said.

I replied in another message too but now SEIZE and INTERRUPT behave
identically.  Any trap clears the condition.

I don't think INTERRUPT can be prioritized like that above existing
trap conditions.  Traps are taken sometimes deep in the kernel
(e.g. fork/exec) and often after modifying states irrevocably
(e.g. signal is already dequeued on signal trap).  I don't think how
it would be possible to rewind the state changes and replay it later.

FWIW, if INTERRUPT exists while signal is pending, INTERRUPT will be
taken first but that doesn't mean all that much as we can't roll back
from traps which already have happened and tracee might be in any trap
by the time PTRACE_INTERRUPT is issued.

Thank you.

-- 
tejun
--
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/