xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Feng Wu <feng.wu@intel.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Cc: Keir Fraser <keir@xen.org>
Subject: Re: [PATCH 2/4] x86: suppress SMAP and SMEP while running 32-bit PV guest code
Date: Wed, 09 Mar 2016 07:03:09 -0700	[thread overview]
Message-ID: <56E03B2D02000078000DADBE@prv-mh.provo.novell.com> (raw)
In-Reply-To: <56DFFEE4.1020008@citrix.com>

>>> On 09.03.16 at 11:45, <andrew.cooper3@citrix.com> wrote:
> On 09/03/16 08:09, Wu, Feng wrote:
> 
>>> --- a/xen/arch/x86/x86_64/entry.S
>>> +++ b/xen/arch/x86/x86_64/entry.S
>>> @@ -434,6 +434,7 @@ ENTRY(dom_crash_sync_extable)
>>>
>>>  ENTRY(common_interrupt)
>>>          SAVE_ALL CLAC
>>> +        SMEP_SMAP_RESTORE
>>>          movq %rsp,%rdi
>>>          callq do_IRQ
>>>          jmp ret_from_intr
>>> @@ -454,13 +455,64 @@ ENTRY(page_fault)
>>>  GLOBAL(handle_exception)
>>>          SAVE_ALL CLAC
>>>  handle_exception_saved:
>>> +        GET_CURRENT(%rbx)
>>>          testb $X86_EFLAGS_IF>>8,UREGS_eflags+1(%rsp)
>>>          jz    exception_with_ints_disabled
>>> -        sti
>>> +
>>> +.Lsmep_smap_orig:
>>> +        jmp   0f
>>> +        .if 0 // GAS bug (affecting at least 2.22 ... 2.26)
>>> +        .org .Lsmep_smap_orig + (.Lsmep_smap_alt_end - .Lsmep_smap_alt), 
> 0xcc
>>> +        .else
>>> +        // worst case: rex + opcode + modrm + 4-byte displacement
>>> +        .skip (1 + 1 + 1 + 4) - 2, 0xcc
>>> +        .endif
>>> +        .pushsection .altinstr_replacement, "ax"
>>> +.Lsmep_smap_alt:
>>> +        mov   VCPU_domain(%rbx),%rax
>>> +.Lsmep_smap_alt_end:
>>> +        .section .altinstructions, "a"
>>> +        altinstruction_entry .Lsmep_smap_orig, .Lsmep_smap_alt, \
>>> +                             X86_FEATURE_SMEP, \
>>> +                             (.Lsmep_smap_alt_end - .Lsmep_smap_alt), \
>>> +                             (.Lsmep_smap_alt_end - .Lsmep_smap_alt)
>>> +        altinstruction_entry .Lsmep_smap_orig, .Lsmep_smap_alt, \
>>> +                             X86_FEATURE_SMAP, \
>>> +                             (.Lsmep_smap_alt_end - .Lsmep_smap_alt), \
>>> +                             (.Lsmep_smap_alt_end - .Lsmep_smap_alt)
>>> +        .popsection
>>> +
>>> +        testb $3,UREGS_cs(%rsp)
>>> +        jz    0f
>>> +        cmpb  $0,DOMAIN_is_32bit_pv(%rax)
>>> +        je    0f
>>> +        call  cr4_smep_smap_restore
>>> +        /*
>>> +         * An NMI or #MC may occur between clearing CR4.SMEP and CR4.SMAP 
> in
>> Do you mean "before" when you typed "between" above?
> 
> The meaning is "between (clearing CR4.SMEP and CR4.SMAP in
> compat_restore_all_guest) and (it actually returning to guest)"
> 
> Nested lists in English are a source of confusion, even to native speakers.

I've switched the first "and" to / to avoid the ambiguity.

Jan


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

  parent reply	other threads:[~2016-03-09 14:03 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-04 11:08 [PATCH 0/4] x86: accommodate 32-bit PV guests with SMAP/SMEP handling Jan Beulich
2016-03-04 11:27 ` [PATCH 1/4] x86/alternatives: correct near branch check Jan Beulich
2016-03-07 15:43   ` Andrew Cooper
2016-03-07 15:56     ` Jan Beulich
2016-03-07 16:11       ` Andrew Cooper
2016-03-07 16:21         ` Jan Beulich
2016-03-08 17:33           ` Andrew Cooper
2016-03-04 11:27 ` [PATCH 2/4] x86: suppress SMAP and SMEP while running 32-bit PV guest code Jan Beulich
2016-03-07 16:59   ` Andrew Cooper
2016-03-08  7:57     ` Jan Beulich
2016-03-09  8:09       ` Wu, Feng
2016-03-09 14:09         ` Jan Beulich
2016-03-09 11:19       ` Andrew Cooper
2016-03-09 14:28         ` Jan Beulich
2016-03-09  8:09   ` Wu, Feng
2016-03-09 10:45     ` Andrew Cooper
2016-03-09 12:27       ` Wu, Feng
2016-03-09 12:33         ` Andrew Cooper
2016-03-09 12:36           ` Jan Beulich
2016-03-09 12:54             ` Wu, Feng
2016-03-09 13:35             ` Wu, Feng
2016-03-09 13:42               ` Andrew Cooper
2016-03-09 14:03       ` Jan Beulich [this message]
2016-03-09 14:07     ` Jan Beulich
2016-03-04 11:28 ` [PATCH 3/4] x86: use optimal NOPs to fill the SMAP/SMEP placeholders Jan Beulich
2016-03-07 17:43   ` Andrew Cooper
2016-03-08  8:02     ` Jan Beulich
2016-03-04 11:29 ` [PATCH 4/4] x86: use 32-bit loads for 32-bit PV guest state reload Jan Beulich
2016-03-07 17:45   ` Andrew Cooper
2016-03-10  9:44 ` [PATCH v2 0/3] x86: accommodate 32-bit PV guests with SMEP/SMAP handling Jan Beulich
2016-03-10  9:53   ` [PATCH v2 1/3] x86: suppress SMEP and SMAP while running 32-bit PV guest code Jan Beulich
2016-05-13 15:48     ` Andrew Cooper
2016-03-10  9:54   ` [PATCH v2 2/3] x86: use optimal NOPs to fill the SMEP/SMAP placeholders Jan Beulich
2016-05-13 15:49     ` Andrew Cooper
2016-03-10  9:55   ` [PATCH v2 3/3] x86: use 32-bit loads for 32-bit PV guest state reload Jan Beulich
     [not found]   ` <56E9A0DB02000078000DD54C@prv-mh.provo.novell.com>
2016-03-17  7:50     ` [PATCH v3 0/4] x86: accommodate 32-bit PV guests with SMEP/SMAP handling Jan Beulich
2016-03-17  8:02       ` [PATCH v3 1/4] x86: move cached CR4 value to struct cpu_info Jan Beulich
2016-03-17 16:20         ` Andrew Cooper
2016-03-17  8:03       ` [PATCH v3 2/4] x86: suppress SMEP and SMAP while running 32-bit PV guest code Jan Beulich
2016-03-25 18:01         ` Konrad Rzeszutek Wilk
2016-03-29  6:55           ` Jan Beulich
2016-05-13 15:58         ` Andrew Cooper
2016-03-17  8:03       ` [PATCH v3 3/4] x86: use optimal NOPs to fill the SMEP/SMAP placeholders Jan Beulich
2016-05-13 15:57         ` Andrew Cooper
2016-05-13 16:06           ` Jan Beulich
2016-05-13 16:09             ` Andrew Cooper
2016-03-17  8:04       ` [PATCH v3 4/4] x86: use 32-bit loads for 32-bit PV guest state reload Jan Beulich
2016-03-25 18:02         ` Konrad Rzeszutek Wilk
2016-03-17 16:14       ` [PATCH v3 5/4] x86: reduce code size of struct cpu_info member accesses Jan Beulich
2016-03-25 18:47         ` Konrad Rzeszutek Wilk
2016-03-29  6:59           ` Jan Beulich
2016-03-30 14:28             ` Konrad Rzeszutek Wilk
2016-03-30 14:42               ` Jan Beulich
2016-05-13 16:11         ` Andrew Cooper
2016-05-03 13:58       ` Ping: [PATCH v3 2/4] x86: suppress SMEP and SMAP while running 32-bit PV guest code Jan Beulich
2016-05-03 14:10         ` Andrew Cooper
2016-05-03 14:25           ` Jan Beulich
2016-05-04 10:03             ` Andrew Cooper
2016-05-04 13:35               ` Jan Beulich
2016-05-04  3:07         ` Wu, Feng
2016-05-13 15:21         ` Wei Liu
2016-05-13 15:30           ` Jan Beulich
2016-05-13 15:33             ` Wei Liu
2016-05-13 17:02       ` [PATCH v3 0/4] x86: accommodate 32-bit PV guests with SMEP/SMAP handling Wei Liu
2016-05-13 17:21         ` Andrew Cooper
2016-06-21  6:19       ` Wu, Feng
2016-06-21  7:17         ` Jan Beulich

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=56E03B2D02000078000DADBE@prv-mh.provo.novell.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=feng.wu@intel.com \
    --cc=keir@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /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).