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, 22 Jan 2010 16:22:22 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Frank Ch. Eigler" <fche@...hat.com>
cc:	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

On Fri, 22 Jan 2010, Linus Torvalds wrote:
>
> No. It's not about naming. It's about the downside of having amorphous 
> interfaces that apparently don't even have rules, and are then used to 
> implement random crap.
> 
> Yes, the SNL skit about "It's a dessert topping _and_ a floor wax" was 
> funny, but it was funny exactly because it was crazy.

Put yet another way: I'd _much_ rather have two totally separate pieces 
that don't depend on each other, and do different things.

So to take a very practical example: I'd much rather have 'seccomp' and 
'ptrace' that have _nothing_ what-so-ever to do with each other, than have 
some intermediate layer that then needs to make both of those happy, and 
that both have to interact with.

There are cases where we really _want_ to have common code. We want to 
have a common VFS interface because we want to show _one_ interface to 
user space across a gazillion different filesystems. We want to have a 
common driver layer (as far as possible) because - again - we expose a 
metric shitload of drivers, and we want to have one unified interface to 
them.

But going the other way: trying to share code when the interfaces are 
fundamentally _different_ is generally not at all such a great idea. It 
ends up tying two conceptually totally separate things together, and 
suddenly people who work on feature X aneed to modify infrastructure that 
affects feature Y, and it turns ou that details A, B and C are all totally 
different for the two features and the middle layer has two conflicting 
things it needs to work with.

This is why when somebody brought up "you could do a seccomp-like thing on 
top of utrace" that my reaction was and is just totally negative. It shows 
all the wrong kinds of tying things together.

			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/