Re: 32bit binaries on x86_64/Xen segfaults in syscall-vdso

[Bastian Blank <waldi@debian.org>]

On Fri, Sep 04, 2009 at 07:46:05PM +0200, Bastian Blank wrote:
> On Fri, Sep 04, 2009 at 09:07:39AM -0700, Jeremy Fitzhardinge wrote:
> > On 09/03/09 15:36, Bastian Blank wrote:
> > > This function looks weird. It tries to restores the user code segment.
> > > But the documentation from AMD explicitely stat that the CS and SS are
> > > restored from the STAR register.
> | #define FLAT_RING3_CS32 0xe023
> | wrmsr(MSR_STAR, 0, (FLAT_RING3_CS32<<16) | __HYPERVISOR_CS);
> But this does not match my observation either.

Well, it does. The values for a long-mode program within Xen:

| cs             0xe033   57395
| ss             0xe02b   57387

Values on the bare hardware:

| cs             0x33     51
| ss             0x2b     43

Values for a compatibility-mode program on the bare hardware:

| cs             0x23     35
| ss             0x2b     43

So Xen adds 0xe000 (no idea what that means), but the Linux kernel
expects the value without.  Long mode is not affected.

Okay, I tried the test program again and yes, it jumps back into
long-mode. (See the 0x10 in the restored CS[1].)

| cs             0xe033   57395
| ss             0xe02b   57387

Bastian

[1]: http://amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf,
     page 151
-- 
Where there's no emotion, there's no motive for violence.
		-- Spock, "Dagger of the Mind", stardate 2715.1