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:	Sat, 23 Jan 2010 06:47:29 -0500
From:	"Frank Ch. Eigler" <fche@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Kyle Moffett <kyle@...fetthome.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Peter Zijlstra <peterz@...radead.org>,
	Fr??d??ric Weisbecker <fweisbec@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Arnaldo Carvalho de Melo <acme@...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

Hi -

mingo wrote:
> [...]
> > Now how do we get from here to a moderately portable API for interrogating, 
> > controlling, and intercepting process state? Essentially it would need to 
> > support all of the things that a powerful debugger would want to do, 
> > including modifying registers and memory, substituting syscall return 
> > values, etc.  I believe that "utrace" is the kernel side of that API.
> 
> The problem is, utrace does not do that really.

In fact, it is exactly designed for that.

> What utrace does is that it provides an opaque set of APIs for
> unspecified and out of tree _kernel_ modules (such as systemtap). It
> doesnt support any 'application' per se. It basically removes the
> kernel's freedom at shaping its own interaction with debug
> application.

This claim is hard to take any more seriously than emoting that the
blockio layer is "opaque" because device drivers "remove freedom" for
the kernel to "shape its interaction" with hardware.  If you have any
*real evidence* about how any present user of utrace misuses that
capability, or interferes with the "kernel's freedom", show us please.


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