linux-kernel - Re: [PATCH 04/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: <20110511192420.GB24245@mtj.dyndns.org>
Date:	Wed, 11 May 2011 21:24:20 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Bryan Donlan <bdonlan@...il.com>
Cc:	Denys Vlasenko <vda.linux@...glemail.com>,
	Oleg Nesterov <oleg@...hat.com>, jan.kratochvil@...hat.com,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, indan@....nu
Subject: Re: [PATCH 04/11] ptrace: implement PTRACE_INTERRUPT

Hello,

On Wed, May 11, 2011 at 12:20:11PM -0400, Bryan Donlan wrote:
> If a process issues PTRACE_INTERRUPT, it just wants the target process
> to stop. Presumably it doesn't really care _why_, as long as it
> doesn't introduce spurious effects visible to the target. As such, if
> the process stops on its own due to some other trap, that ought to be
> good enough, right? Is there really a need for a trap that will be
> reliably echoed back to the trapping process?

It can go either way.  I just chose one.  One use case which made me
favor not clearing INTERRUPT on other traps was that INTERRUPT, along
with group stop trap, is special in that it allows notification
re-traps.  It serves as per-tracee job control trap site which
debugger can use as it pleases.

As such, there are times where debugger wants to put tracee into that
specific trap.  If INTERRUPT gets cleared on every trap, it would have
to set INTERRUPT on each trap until it reaches INTERRUPT trap which
seemed kinda silly and given that INTERRUPT may happen for spurious
notification reasons, there didn't seem much point in avoiding the
trap because there was another trap.

That said, as it makes INTERRUPT behavior different from SEIZE and I
think occassional multiple traps on SEIZE could be uglier.  I think
I'll change it such that it clears on any trap.  If debugger wants to
put tracee specifically into INTERRUPT trap, it will have to raise it
after each unsuccessful trap.  It would be annoying but I suppose it's
lesser of the two evils.

Thanks.

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