[lkml]   [2012]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
SubjectRe: Compat 32-bit syscall entry from 64-bit task!?
On Thu, Jan 19, 2012 at 1:21 PM, Linus Torvalds
<> wrote:
> 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
> rflags).

Would it be worth considering changing the return from
task_user_regset_view, like:

--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -1311,7 +1311,11 @@ void update_regset_xstate_info(unsigned int
size, u64 xstate_mask)
const struct user_regset_view *task_user_regset_view(struct task_struct *task)
- if (test_tsk_thread_flag(task, TIF_IA32))
+ /* If the task is in a syscall, then the TS_COMPAT status
+ * is more accurate than the personality.
+ */
+ if (test_tsk_thread_flag(task, TIF_IA32) ||
+ task_thread_info(task)->status & TS_COMPAT)
#if defined CONFIG_X86_32 || defined CONFIG_IA32_EMULATION
return &user_x86_32_view;

This would make TS_COMPAT behave like a personality change.
PTRACE_POKEUSR and PEEKUSR would still access the 64-bit view with no
compat info (just like with TIF_IA32 tasks), but PTRACE_[GS]ETREGS
would return/expect 32-bit struct user_struct_regs. This would result
in the tracer needing to check the returned regs to see if it was
fully populated (which seems heinous), but it would export the
TS_COMPAT state.

Right now, if a 64-bit tracer changes the regs for a TS_COMPAT call,
the args will be 32-bit truncated (for better or worse). Of course, on
trace_syscall_leave, 64-bit registers won't be truncated so it maybe
makes less sense.

Perhaps this was considered and discarded as being obviously broken,
but it wasn't clear cut to me.

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-20 16:39    [W:0.220 / U:7.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site