linux-kernel - Re: [PATCH 13/X] uprobes: introduce UTASK_SSTEP

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: <20111022072030.GB24475@in.ibm.com>
Date:	Sat, 22 Oct 2011 12:50:30 +0530
From:	Ananth N Mavinakayanahalli <ananth@...ibm.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>,
	Steven Rostedt <rostedt@...dmis.org>,
	Linux-mm <linux-mm@...ck.org>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jonathan Corbet <corbet@....net>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Hugh Dickins <hughd@...gle.com>,
	Christoph Hellwig <hch@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andi Kleen <andi@...stfloor.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jim Keniston <jkenisto@...ux.vnet.ibm.com>,
	Roland McGrath <roland@...k.frob.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 13/X] uprobes: introduce UTASK_SSTEP_TRAPPED logic

On Wed, Oct 19, 2011 at 11:53:44PM +0200, Oleg Nesterov wrote:
> Finally, add UTASK_SSTEP_TRAPPED state/code to handle the case when
> xol insn itself triggers the signal.
> 
> In this case we should restart the original insn even if the task is
> already SIGKILL'ed (say, the coredump should report the correct ip).
> This is even more important if the task has a handler for SIGSEGV/etc,
> The _same_ instruction should be repeated again after return from the
> signal handler, and SSTEP can never finish in this case.

Oleg,

Not sure I understand this completely...

When you say 'correct ip' you mean the original vaddr where we now have
a uprobe breakpoint and not the xol copy, right?

Coredump needs to report the correct ip, but should it also not report
correctly the instruction that caused the signal? Ergo, shouldn't we
put the original instruction back at the uprobed vaddr?

Ananth

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