linux-kernel - Re: [PATCHv11 2.6.36-rc2-tip 3/15] 3: uprobes: Slot allocation for Execution out of line(XOL)

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 2 Sep 2010 23:17:12 +0530
From:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Steven Rostedt <rostedt@...dmis.org>,
	Randy Dunlap <rdunlap@...otime.net>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Christoph Hellwig <hch@...radead.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Mark Wielaard <mjw@...hat.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Naren A Devaiah <naren.devaiah@...ibm.com>,
	Jim Keniston <jkenisto@...ux.vnet.ibm.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: Re: [PATCHv11 2.6.36-rc2-tip 3/15]  3: uprobes: Slot allocation
 for Execution out of line(XOL)

> > Current slot allocation mechanism:
> > 1. Allocate one dedicated slot per user breakpoint. Each slot is big
> > enuf to accomodate the biggest instruction for that architecture. (16
> > bytes for x86).
> > 2. We currently allocate only one page for slots. Hence the number of
> > slots is limited to active breakpoint hits on that process.
> > 3. Bitmap to track used slots. 
> 
> An alternative method would be to have 1 slot per cpu, and manage the
> slot content using preemption notifiers. That gives you a fixed number
> of slots and an unlimited number of probe points.
> 
> If the preemption happens to be a migration you need to rewrite the
> userspace IP to point to the new slot -- if indeed the task was inside
> one when it got preempted -- but that all should be doable.
> 

Certainly doable but it has its share of drawbacks.
1. On every probe hit we have to copy the instruction into the
slot, so there is a performance penalty. 

2  This might complicate booster probe, because the jump
instruction that follows the original instruction now actually have to
coded every time.

3. Yes migration is an issue esp
-  if a thread of the same process that hit a breakpoint is scheduled into the same cpu and that newly scheduled thread hits a breakpoint. 
- Something similar can happen if a multithreaded process runs on a
  uniprocessor machine.

4. I dont see a need for clearing slots after post processing, but if
we need to clear we then are adding more penalties because not only are
we clearing the slots but the post processing then cant happen in
interrupt context.

5. I think we are covered on the cpu hotplug too, (i.e not sure if we have
to make uprobes cpu hot plug aware.).

6. We would still be allocating a page for the slots. Unless we want
to expand to more slots than available in one page, I dont see the
disadvantages with the current approach.

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