Messages in this thread | | | Date | Fri, 4 Sep 2009 20:19:39 +0200 | From | Bastian Blank <> | Subject | Re: 32bit binaries on x86_64/Xen segfaults in syscall-vdso |
| |
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
| |