Date:	Mon, 06 Feb 2012 09:02:37 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Indan Zupancic <indan@....nu>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	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,
	Roland McGrath <mcgrathr@...omium.org>,
	"H.J. Lu" <hjl.tools@...il.com>
Subject: Re: Compat 32-bit syscall entry from 64-bit task!?

On 02/06/2012 12:32 AM, Indan Zupancic wrote:
> 
> It seems that just using eflags is a lot simpler than the alternatives,
> let's just go for it.
> 
> 
> I propose using bits somewhere in the middle of the upper half. If new
> flags are ever added by Intel or AMD, they will use the lower bits. If
> anyone else ever adds flags, they most likely add them to the top (VIA).
> So the middle seems the safest spot as far as long-term maintenance goes.
> 
> The below version does that, but instead of setting one of the two bits,
> it always sets bit 50 for newer kernels and sets bit 51 if it's a compat
> system call. I find this version more readable and after compilation it's
> also a couple of bytes smaller compared to Linus' original version.
> 
> Should we make sure that the top 32 bits are zero, in case any weird
> hardware does set our bits?
> 

[Adding H.J. Lu, since he has run into some of these requirements before]

NAK in the extreme.

We have not heard back from the architecture people on this, and I will
NAK this unless that happens.

Furthermore, you're picking bits that do not work for 32 bits, EVEN
THOUGH WE HAVE A SIMILAR PROBLEM ON 32 BITS; I outlined it for you and
you chose to ignore it.

Finally, I think we actually are going to need a fair number of bits in
the end.  All of this points to using a new regset designed for
extension in the first place.

As far as I can tell, we need at least the following information:

- If the CPU is currently in 32- or 64-bit mode.
- If we are currently inside a system call, and if so if it was entered
  via:
	- SYSCALL64
	- INT 80
	- SYSCALL32
	- SYSENTER

  The reason we need this information is because for the various 32-bit
  entry points we do some very ugly swizzling of registers, which
  matters to a ptrace client which wants to modify system call
  arguments.
- If the process was started as a 64-bit process, i386 process or x32
  process.

This adds up to a minimum of six bits already (and at least two bits on
i386), and that's just a start.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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