linux-kernel - Re: [PATCH v1 0/10] Uprobes patches.

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:	Mon, 22 Mar 2010 21:38:36 -0400
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
Cc:	Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	Mel Gorman <mel@....ul.ie>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	Jim Keniston <jkenisto@...ux.vnet.ibm.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 0/10] Uprobes patches.

On Sat, 20 Mar 2010 19:54:55 +0530 Srikar Dronamraju <srikar@...ux.vnet.ibm.com> wrote:

> This patchset implements Uprobes which enables you to dynamically break
> into any routine in a user space application and collect information
> non-disruptively.

What's missing here is a description of why all this is useful. 
Presumably much of the functionality which this feature offers can be
done wholly in userspace.  So I think it would be useful if you were to
carefully explain the thinking here - what the value is, how people
will use it, why it needs to be done in-kernel, etc.  Right now if I
was asked "why did you merge that", I'd say "gee, I dunno".  I say that
a lot.  Knowing all of this would perhaps help me to understand your
thinking regarding ftrace integration.

The code itself is positioned as non-x86-specific, but the
implementation is x86-only.  It would be nice to get some confirmation
that other architectures can successfully use the core code.  But that
will be hard to arrange, so probably crossing our fingers is the best
approach here.

The code scares me a bit from the "how can malicious people exploit it"
point of view.  Breaking into other users programs/memory, causing the
kernel to scribble on itself, causing unbound memory consumption, etc. 
No specific issues that I can point at, just vague fear.

Do we know that exiting userspace will never ever already be using int3?

What happens if I run this code in 2016 on a CPU which has new opcodes
which this code didn't know about?

When uprobes was being pushed five-odd years ago, it did all sorts of
hair-raising things to avoid COWing shared pages.  Lots of reasons were
given why it *had* to avoid COW.  But now it COWs.  What were those
reasons why COW was unacceptable, and what changed?

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