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]

Date:	Fri, 29 Jan 2010 10:25:46 +0530
From:	Ananth N Mavinakayanahalli <ananth@...ibm.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Jim Keniston <jkenisto@...ibm.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Kyle Moffett <kyle@...fetthome.net>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	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,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: linux-next: add utrace tree

On Thu, Jan 28, 2010 at 09:55:02AM +0100, Ingo Molnar wrote:

...

> Lets compare the two cases via a drawing. Your current uprobes submission 
> does:
> 
>  [kernel]      do probe thing     single-step trap
>                ^            |     ^              |
>                |            v     |              v
>  [user]     INT3            XOL-ins              next ins-stream
> 
>  ( add the need for serialization to make sure the whole single-step thing 
>    does not get out of sync with reality. )
> 
> And emulator approach would do:
> 
>  [kernel]      emul-demux-fastpath, do probe thing
>                ^                                 |
>                |                                 v
>  [user]     INT3                                 next ins-stream
> 
> far simpler conceptually, and faster as well, because it's one kernel entry.

Ingo,

Yes, conceptually, emulation is simpler. In fact, it may even be the
right thing to do from a housekeeping POV if gdb were enabled to use
breakpoint assistance in the kernel. However... emulation is not
easy. Just quoting Peter Anvin:

> On the more general rule of interpretation: I'm really concerned about
> having a bunch of partially-capable x86 interpreters all over the
> kernel.  x86 is *hard* to emulate, and it will only get harder as the
> architecture evolves.
>
>       -hpa

Yes, I know you suggested we start with a small subset.

We already have an implementation of instruction emulation in kernel for
x86 and powerpc, but its too KVM centric. If there is a generic
emulation layer, we would use it.

There are conflicting opinions for either case; complicated as it is,
the XOL scheme works and, to a large extent, it is easily extendable to
other architectures compared to the emulation approach. Uprobes can be
made to use emulation when possible/available, but I don't think this
should be gating decision for the initial implementation of the feature.

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/