lkml.org 
[lkml]   [2012]   [Jan]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Compat 32-bit syscall entry from 64-bit task!?
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)
{
#ifndef CONFIG_PARAVIRT
/*
* On non-paravirt systems, this is the only long mode CPL 3
* selector. We do not allow long mode selectors in the LDT.
*/
return regs->cs == __USER_CS;
#else
/* Headers are too twisted for this to go in paravirt.h. */
return regs->cs == __USER_CS || regs->cs == pv_info.extra_user_64bit_cs;
#endif
}

Perhaps userspace can do that.
Would it be right for a ptracer to say:

CS == 0x23 -> 32-bit
(CS & 4) -> 32-bit (LDT, "we do not allow long mode selectors in the LDT")
else -> 64-bit (__USER_CS or some other GDT entry which must be pv_info's)

I.e. assume that no other *GDT* CS values are available to userspace?
There are other 32-bit GDT entries, but are they not all for data or kernel use only?

-- Jamie


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