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:	Thu, 21 Jan 2010 18:35:26 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Frank Ch. Eigler" <fche@...hat.com>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Ingo Molnar <mingo@...e.hu>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	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

On Thu, 21 Jan 2010, Frank Ch. Eigler wrote:
> 
> Less passionate analysis would identify a long history of contribution
> by the the greater affiliated team, including via merged code and by
> and passing on requirements and experiences.

The reason I'm so passionate is that I dislike the turn the discussion was 
taking, as if "utrace" was somehow _good_ because it allowed various other 
interfaces to hide behind it. And I'm not at all convinced that is true. 

And I really didn't want to single out system tap, I very much feel the 
same way abotu some seccomp-replacement "security model that the kernel 
doesn't even need to know about" thing.

So don't take the systemtap part to be the important part, it's the bigger 
issue of "I'd much rather have explicit interfaces than have generic hooks 
that people can then use in any random way".

I realize that my argument is very anti-thetical to the normal CS teaching 
of "general-purpose is good". I often feel that very specific code with 
very clearly defined (and limited) applicability is a good thing - I'd 
rather have just a very specific ptrace layer that does nothing but 
ptrace, than a "generic plugin layer that can be layered under ptrace and 
other things".

In one case, you know exactly what the users are, and what the semantics 
are going to be. In the other, you don't. 

So I really want to see a very big and immediate upside from utrace. 
Because to me, the "it's a generic layer with any application you want to 
throw at it" is a _downside_.

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