Re: Compat 32-bit syscall entry from 64-bit task!?
From: H. Peter Anvin
Date: Mon Feb 06 2012 - 12:06:15 EST
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
- INT 80
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
- If the process was started as a 64-bit process, i386 process or x32
This adds up to a minimum of six bits already (and at least two bits on
i386), and that's just a start.
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/