[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrXucLLf8RH_yocV3jpsKPMaqmP3gM2os=kEQ=wjwT0S6Q@mail.gmail.com>
Date: Tue, 15 Jul 2014 09:00:19 -0700
From: Andy Lutomirski <luto@...capital.net>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
stable <stable@...r.kernel.org>
Subject: Re: [PATCH] x86_64,xen,espfix: Initialize espfix on secondary CPUs
On Tue, Jul 15, 2014 at 8:50 AM, H. Peter Anvin <hpa@...or.com> wrote:
> On 07/15/2014 08:38 AM, Konrad Rzeszutek Wilk wrote:
>>
>> I think just disallowing would be preferrable.
>>
>
> So I have yet to hear anyone talk about what the Xen PV IRET does for
> 16-bit stack segments. Can we get the answer for that, please?
>
If I'm reading the right thing, it does:
59 .Lforce_iret:
60 /* Mimic SYSRET behavior. */
61 movq 8(%rsp),%rcx # RIP
62 movq 24(%rsp),%r11 # RFLAGS
63 ALIGN
64 /* No special register assumptions. */
65 iret_exit_to_guest:
66 addq $8,%rsp
67 .Lft0: iretq
while running on Xen's stack. IOW, it leaks bits 31:16 of the Xen
stack, and there's nothing the guest can do about it short of using a
user-mode trampoline or disabling 16-bit stack segments entirely.
See:
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/x86_64/entry.S;h=a3ed216b390c2e87a21ff377850ee34ee7f2bc74;hb=HEAD
and (search for do_iret):
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/traps.c;h=677074b4e628ed99d407b1045d859355e590d604;hb=HEAD
> -hpa
>
>
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists