On Thu, Jan 19, 2012 at 8:01 AM, Jamie Lokier <jamie@xxxxxxxxxxxxx> wrote:
> Andrew Lutomirski wrote:
>> It's reasonable, obvious, and even more wrong than it appears. On
>> Xen, there's an extra 64-bit GDT entry, and it gets used by default.
>> (I got bitten by this in some iteration of the vsyscall emulation
>> patches -- see user_64bit_mode for the correct and
>> unusable-from-user-mode way to do this.)
>
> Here it is:
>
> static inline bool user_64bit_mode(struct pt_regs *regs)
This is pointless, even if it worked, which it clearly doesn't on Xen
(or other random situations).
Why would you care?
The issue is *not* whether somebody is running in 32-bit mode or 64-bit mode.
The problem is the system call itself, and that can be 32-bit or
64-bit independently of the execution mode. So knowing the user-mode
mode is simply not relevant.
In the kernel, we know this with the TS_COMPAT flag - exactly because
it's impossible to tell from any actual CPU state. So *that* is the
flag you need to figure out, and currently the kernel doesn't export
it any way (but my suggested patch would export it in the high bits of
rflags).
So looking at CS isn't *ever* going to help.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
