[lkml]   [2012]   [Jan]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Compat 32-bit syscall entry from 64-bit task!?
On Thu, Jan 19, 2012 at 8:01 AM, Jamie Lokier <> 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

So looking at CS isn't *ever* going to help.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2012-01-19 20:25    [W:0.238 / U:4.196 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site