linux-kernel - Re: Compat 32-bit syscall entry from 64-bit task!?

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: <CA+55aFw3kv_JRsSCQEf6fQd0gX939MuoevDxFtcXkPY+bmyjtA@mail.gmail.com>
Date:	Wed, 18 Jan 2012 15:28:54 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Roland McGrath <mcgrathr@...gle.com>,
	Indan Zupancic <indan@....nu>,
	Andi Kleen <andi@...stfloor.org>,
	Jamie Lokier <jamie@...reable.org>,
	Andrew Lutomirski <luto@....edu>,
	Oleg Nesterov <oleg@...hat.com>,
	Will Drewry <wad@...omium.org>, linux-kernel@...r.kernel.org,
	keescook@...omium.org, john.johansen@...onical.com,
	serge.hallyn@...onical.com, coreyb@...ux.vnet.ibm.com,
	pmoore@...hat.com, eparis@...hat.com, djm@...drot.org,
	segoon@...nwall.com, rostedt@...dmis.org, jmorris@...ei.org,
	scarybeasts@...il.com, avi@...hat.com, penberg@...helsinki.fi,
	viro@...iv.linux.org.uk, mingo@...e.hu, akpm@...ux-foundation.org,
	khilman@...com, borislav.petkov@....com, amwang@...hat.com,
	ak@...ux.intel.com, eric.dumazet@...il.com, gregkh@...e.de,
	dhowells@...hat.com, daniel.lezcano@...e.fr,
	linux-fsdevel@...r.kernel.org,
	linux-security-module@...r.kernel.org, olofj@...omium.org,
	mhalcrow@...gle.com, dlaor@...hat.com
Subject: Re: Compat 32-bit syscall entry from 64-bit task!?

On Wed, Jan 18, 2012 at 1:53 PM, H. Peter Anvin <hpa@...or.com> wrote:
>
> I think we can obviously agree that regsets is the only way to go for
> any kind of new state.

So I really don't necessarily agree at all.

Exactly because there is a heavy burden to introducing new models.
It's not only relatively much more kernel code, it's also relatively
much more painful for user code. If we can hide it in existing
structures, user code is *much* better off, because any existing code
to get the state will just continue to work. Otherwise, you need to
have the code to figure out the new structures (how do you compile it
without the new kernel headers?), you need to do the extra accesses
conditionally etc etc.

There's a real cost to introducing new interfaces. There's a *reason*
people try to make do with old ones.

          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/