| 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
| ||
|
Message-ID: <AANLkTikyU27CtRgWW4pbdqL9jVYevazTW-t0XBFJ-EeC@mail.gmail.com> Date: Wed, 2 Mar 2011 12:02:37 +0100 From: Denys Vlasenko <vda.linux@...glemail.com> To: Tejun Heo <tj@...nel.org> Cc: Oleg Nesterov <oleg@...hat.com>, Roland McGrath <roland@...hat.com>, jan.kratochvil@...hat.com, linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org, akpm@...ux-foundation.org Subject: Re: [RFC] Proposal for ptrace improvements On Wed, Mar 2, 2011 at 8:32 AM, Tejun Heo <tj@...nel.org> wrote: > On Tue, Mar 01, 2011 at 11:59:02PM +0100, Denys Vlasenko wrote: >> We also have magic SIGSTOPs (magic in a sense they aren't >> real signals sent by other processes): >> * at PTRACE_ATTACH >> * in child (if PTRACE_O_TRACE[V]FORK or PTRACE_O_TRACECLONE opt is on) >> >> For example, flagging PTRACE_ATTACH SIGSTOP so that it can be >> uniquely identified would solve some problems gdb is having with it. > > This, I don't agree with. All we need is a better attach call without > the implied SIGSTOP, there's no reason to diddle with PTRACE_ATTACH > further. Sure. What do you think about SIGSTOP generated in in children on auto-attach via PTRACE_O_TRACE[V]FORK / PTRACE_O_TRACECLONE options? IMHO, it would be good if we'd have a way to distinguish them from real SIGSTOP signals. -- vda -- 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/
Powered by blists - more mailing lists