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: <20100123114729.GA7828@redhat.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ