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: <20110516132123.GA13544@host1.jankratochvil.net>
Date:	Mon, 16 May 2011 15:21:23 +0200
From:	Jan Kratochvil <jan.kratochvil@...hat.com>
To:	Tejun Heo <tj@...nel.org>
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]

Hi Tejun,

On Mon, 16 May 2011 10:31:13 +0200, Tejun Heo wrote:
> First of all, I don't think hitting different trap spots would be that
> difficult.  Handling different traps after SEIZE might not be easy but
> could just be something which needs to be done anyway.  I'm reluctant
> to treat the initial trap differently because it's essentially
> identical to what happens when a program does PTRACE_INTERRUPT.  It's
> just something the program should be able to deal with, somewhat like
> read(2) may return shorter amount of data than provided buffer.

If not clear I would like also PTRACE_INTERRUPT to deliver the INTERRUPT event
always as the first one, if it is not clear.

tracer            tracee                                foreign process
---------------   ------                                ---------------
attaches tracee                                        
normal run                                             
                                                        tkill(tracee, SIGUSR1)
                  stopped, to report SIGUSR1 to tracer
PTRACE_INTERRUPT  (but tracee is already stopped)
waitpid(tracee)

Currently that waitpid will report SIGUSR1 first and then the INTERRUPT trap.

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.

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


Thanks,
Jan
--
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/