linux-kernel - Re: [RFC PATCH] set TASK_TRACED before arch

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: <3877989d0805222224n77ce36b6wdf15c4bab330a0f8@mail.gmail.com>
Date:	Fri, 23 May 2008 13:24:44 +0800
From:	"Luming Yu" <luming.yu@...il.com>
To:	"Roland McGrath" <roland@...hat.com>
Cc:	"Petr Tesarik" <ptesarik@...e.cz>,
	LKML <linux-kernel@...r.kernel.org>, linux-ia64@...r.kernel.org
Subject: Re: [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a race

> This is the key thing that makes no sense to me.  What do you mean by
> "deliver" here?  The normal meaning of to "deliver" a signal means that
> get_signal_to_deliver() dequeues and processes it.  This can never happen
> inside any other kernel code path.  It certainly can never happen inside
> ptrace_stop or ptrace_notify.

"deliver" here I mean get_signal_to_deliver()...
Please clarify, in ptrace_notify code path, is it allowed that ptraced
thread can ignore signals (such as SIGTRAP) without telling debugger
what happened? This is key problem I'm not quite sure... Because if
the test doesn't block SIGTRAP, it works on IA64 too.. Hope I have
made the problem clear...
--
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/