On Tue, Jul 26, 2011 at 4:48 PM, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
> 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
>>> 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.
But it's still weird, because AFAICT xen_sysret64 already does the
right thing. So presumably the failure case only happens when
something prevents sysret from working, like CONFIG_AUDITSYSCALL.
>> 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
> from Xen.
That sounds simpler. It will also make Xen userspace look more like
> -- Keir
>> Xen-devel mailing list
Xen-devel mailing list