On 26/07/2011 20:08, "Andrew Lutomirski" <luto@xxxxxxx> wrote:
> On Tue, Jul 26, 2011 at 11:32 AM, Konrad Rzeszutek Wilk
> <konrad.wilk@xxxxxxxxxx> wrote:
>> On Mon, Jul 25, 2011 at 09:50:30PM -0400, Andrew Lutomirski wrote:
>>> After staring at the Xen assembly code with vague comprehension, I
>>> think I can sort of understand what's going on.
>>> Can you run this little program on a working kernel and tell me what
>>> it says (built as 64-bit and as 32-bit (with -m32)):
>> [konrad@f13-x86-build ~]$ ./check
>> cs = 73
>> [konrad@f13-x86-build ~]$ uname -a
>> Linux f13-x86-build.dumpdata.com 3.0.0 #1 SMP PREEMPT Tue Jul 26 09:56:38 EDT
>> 2011 i686 i686 i386 GNU/Linux
>> [konrad@f13-amd64-build ~]$ ./check
>> cs = e033
> My best guess is that each task starts out with standard __USER_CS,
> but the code in write_stack_trampoline (in the hypervisor) tells the
> kernel that CS is 0xe033 and then the next return to userspace makes
> it true.
Yes, that's right.
> I'll hack up a patch to avoid the crash. I'll feel better about it if
> you or any of the Xen gurus can confirm that explanation. If I'm
> right, I need to check for both __USER_CS and FLAT_RING3_CS.
Either that, or Linux needs to poke its preferred 32- or 64-bit user CS
value into the return stackframe when it receives a syscall notification
> Xen-devel mailing list
Xen-devel mailing list