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]

Date:	Wed, 11 May 2011 12:20:11 -0400
From:	Bryan Donlan <bdonlan@...il.com>
To:	Tejun Heo <tj@...nel.org>
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

On Wed, May 11, 2011 at 09:22, Tejun Heo <tj@...nel.org> wrote:
> Hey,
>
> On Wed, May 11, 2011 at 02:23:44PM +0200, Denys Vlasenko wrote:
>> I understand this. I am trying to understand what feature are you trying
>> to provide to userland, or what problematic race scenario you are trying
>> to make resolve-able *in userland* by making "stop" and "cont"
>> notifications sticky wrt GETSIGINFO. I just don't see this scenario.
>
> If you still don't see how events can get lost, I'm afraid I can't
> explain any better.  You're repeating that exit_code can record the
> event until it's fetched but it doesn't queue and any trap will
> overwrite it and debuggers don't have to call GETSIGINFO after each
> trap - it only has to do so for signal delivery, group stop and
> INTERRUPT trap.  So, it can just look at the exit_code (which doesn't
> indicate continuation) and let tracee return to userland.
>
> Maybe I'm horribly confused.  Oleg, am I?

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