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
| ||
|
Date: Sun, 8 Feb 2009 17:50:29 -0800 (PST) From: Roland McGrath <roland@...hat.com> To: Oleg Nesterov <oleg@...hat.com> Cc: Andrew Morton <akpm@...ux-foundation.org>, Jerome Marchand <jmarchan@...hat.com>, Denys Vlasenko <dvlasenk@...hat.com>, linux-kernel@...r.kernel.org Subject: Re: [PATCH 3/3] ptrace_untrace: fix the SIGNAL_STOP_STOPPED check Yes, I believe this is correct. It matches the flip side of the bookkeeping where we adjust group_stop_count when going into TASK_TRACED (ptrace_stop). I think it warrants a comment with your change, saying that treating group_stop_count as "we should be already stopped" is consistent with decrementing an active group_stop_count when we enter TASK_TRACED. > - if the process/thread was traced, SIGNAL_STOP_STOPPED > does not necessary means this thread group is stopped. > > - ptrace breaks the bookkeeping of ->group_stop_count. SIGNAL_STOP_STOPPED is only set when all live threads in the group are in either TASK_TRACED or TASK_STOPPED. PTRACE_DETACH respects this and this it stopped. However, PTRACE_CONT et al (ptrace_resume) do not respect it and can resume an individual thread regardless of SIGNAL_STOP_STOPPED. That's what you mean here, right? Doing that without a SIGCONT having been generated is an anomalous way for a debugger to behave, since it's going to eat the effects of the job control stop. But who knows that things they do, so this could be sticky to fix so that SIGNAL_STOP_STOPPED really means all stopped. > (the comment above ptrace_untrace() doesn't look exactly right too). How so? Thanks, Roland -- 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