linux-kernel - Re: linux-next: add utrace tree

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: <20100127110722.GA28678@linux.vnet.ibm.com>
Date:	Wed, 27 Jan 2010 16:37:22 +0530
From:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Kyle Moffett <kyle@...fetthome.net>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Fr??d??ric Weisbecker <fweisbec@...il.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Tom Tromey <tromey@...hat.com>,
	"Frank Ch. Eigler" <fche@...hat.com>, linux-next@...r.kernel.org,
	"H. Peter Anvin" <hpa@...or.com>, utrace-devel@...hat.com,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: linux-next: add utrace tree

* Linus Torvalds <torvalds@...ux-foundation.org> [2010-01-27 02:43:39]:

> 
> 
> On Wed, 27 Jan 2010, Peter Zijlstra wrote:
> > 
> > Right, so you're going to love uprobes, which does exactly that. The
> > current proposal is overwriting the target instruction with an INT3 and
> > injecting an extra vma into the target process's address space
> > containing the original instruction(s) and possible jumps back to the
> > old code stream.
> 
> Just out of interest, how does it handle the threading issue?

I am not sure why threading would be an issue with XOL. Since all
threads of a process would have access to the XOL VMA. 
i.e This XOL VMA is a per-process VMA that gets attached to the process address space 
only when we hit the first breakpoint.
We reserve a slot for each breakpoint in the XOL VMA, whenever the trap
is hit, we jump to the corresponding slot, single step and jump back
after necessary fix-ups.
We have been able to use this approach in multithreaded applications. 
However if you see any issues, can you please let us know?

> 
> Last I saw, at least some CPU people were _very_ nervous about overwriting 
> instructions if another CPU might be just about to execute them.
> 
> Even the "overwrite only the first byte with 'int3'" made them go "umm, I 
> need to talk to some core CPU people to see if that's ok". They mumble 
> about possible CPU errata, I$ coherency, instruction retry etc.

Thats exactly why we waited for threads to queisce before inserting and
deleting the breakpoints. However we were advised by lkml that there are 
better ways to insert/delete breakpoints without quiescing by adjusting
the page table entries similar to what you said just below. And we are
working on switching the page table entry solution.

> 
> I realize kprobes does this very thing, but kprobes is esoteric stuff and 
> doesn't have much choice. In user space, you _could_ do the modification 
> on a different physical page and then just switch the page table entry 
> instead, and not get into the whole D$/I$ coherency thing at all.
> 
> 				Linus
> 

--
Thanks and Regards
Srikar
--
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/