xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Luis R. Rodriguez" <mcgrof@kernel.org>
To: Andy Lutomirski <luto@kernel.org>
Cc: xen-devel@lists.xensource.com,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	x86@kernel.org, "Luis R. Rodriguez" <mcgrof@kernel.org>,
	lguest@lists.ozlabs.org, Borislav Petkov <bp@alien8.de>,
	david.vrabel@citrix.com, boris.ostrovsky@oracle.com
Subject: Re: [PATCH v2 1/2] x86/entry/32: Introduce and use X86_BUG_ESPFIX instead of paravirt_enabled
Date: Wed, 2 Mar 2016 00:11:38 +0100	[thread overview]
Message-ID: <20160301231138.GG25240@wotan.suse.de> (raw)
In-Reply-To: <5cf8d92df1ad2965a2d8cdbb466af04da8dbbbc1.1456789731.git.luto@kernel.org>

On Mon, Feb 29, 2016 at 03:50:19PM -0800, Andy Lutomirski wrote:
> x86_64 has very clean espfix handling on paravirt: espfix64 is set
> up in native_iret, so paravirt systems that override iret bypass
> espfix64 automatically.  This is robust and straightforward.

This I think I get as all the ESP hackery is on native_iret():

arch/x86/entry/entry_64.S
ENTRY(native_iret)                                                              
        /*                                                                      
         * Are we returning to a stack segment from the LDT?  Note: in          
         * 64-bit mode SS:RSP on the exception stack is always valid.           
         */                                                                     
#ifdef CONFIG_X86_ESPFIX64                                                      
        testb   $4, (SS-RIP)(%rsp)                                              
        jnz     native_irq_return_ldt                                           
#endif 

native_iret is simply expected to not be used on paravirt systems.

> x86_32 is messier.  espfix is set up before the IRET paravirt patch
> point, so it can't be directly conditionalized on whether we use
> native_iret.

This I don't quite get.

I see on paravirt.h:                                                              
                                                                                
#define INTERRUPT_RETURN                                                \       
        PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_iret), CLBR_NONE,       \       
                  jmp PARA_INDIRECT(pv_cpu_ops+PV_CPU_iret))  

The rest is unclear, in particular how this would be late.

  Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  parent reply	other threads:[~2016-03-01 23:11 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-29 23:50 [PATCH v2 0/2] x86/entry/32: Get rid of paravirt_enabled in ESPFIX Andy Lutomirski
     [not found] ` <cover.1456789731.git.luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2016-02-29 23:50   ` [PATCH v2 1/2] x86/entry/32: Introduce and use X86_BUG_ESPFIX instead of paravirt_enabled Andy Lutomirski
2016-03-01 14:00     ` Boris Ostrovsky
     [not found]       ` <56D5A095.4050102-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2016-03-01 15:44         ` Andy Lutomirski
2016-03-01 22:06           ` Luis R. Rodriguez
2016-03-02  0:15       ` Luis R. Rodriguez
     [not found]         ` <20160302001554.GH25240-B4tOwbsTzaBolqkO4TVVkw@public.gmane.org>
2016-03-03  0:33           ` Andy Lutomirski
2016-03-03  1:01             ` Luis R. Rodriguez
2016-03-01 23:11     ` Luis R. Rodriguez [this message]
     [not found]     ` <5cf8d92df1ad2965a2d8cdbb466af04da8dbbbc1.1456789731.git.luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2016-03-04  9:38       ` Borislav Petkov
2016-02-29 23:50   ` [PATCH v2 2/2] x86/asm-offsets: Remove PARAVIRT_enabled Andy Lutomirski
     [not found]     ` <b8adc42d21ea64d84589f8ee7540f8299df21577.1456789731.git.luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2016-03-04  9:38       ` Borislav Petkov
2016-03-01 22:45 ` [PATCH v2 0/2] x86/entry/32: Get rid of paravirt_enabled in ESPFIX Borislav Petkov
     [not found]   ` <20160301224512.GF22677-fF5Pk5pvG8Y@public.gmane.org>
2016-03-03  0:47     ` Andy Lutomirski
     [not found]       ` <CALCETrUcgHKYKn-K4EHF3mCOpuO3cW6Qnpa4k2ydKUAWVpQsSg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-03-03 10:18         ` Borislav Petkov
     [not found]           ` <20160303101807.GA24621-fF5Pk5pvG8Y@public.gmane.org>
2016-03-03 23:49             ` Andy Lutomirski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160301231138.GG25240@wotan.suse.de \
    --to=mcgrof@kernel.org \
    --cc=andrew.cooper3@citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=bp@alien8.de \
    --cc=david.vrabel@citrix.com \
    --cc=lguest@lists.ozlabs.org \
    --cc=luto@kernel.org \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).