All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: "Wu, Feng" <feng.wu@intel.com>, Jan Beulich <JBeulich@suse.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, 9 Mar 2016 10:45:56 +0000	[thread overview]
Message-ID: <56DFFEE4.1020008@citrix.com> (raw)
In-Reply-To: <E959C4978C3B6342920538CF579893F00C369E91@SHSMSX104.ccr.corp.intel.com>

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.

~Andrew

>> +         * compat_restore_all_guest and it actually returning to guest
>> +         * context, in which case the guest would run with the two features
>> +         * enabled. The only bad that can happen from this is a kernel mode
>> +         * #PF which the guest doesn't expect. Rather than trying to make the
>> +         * NMI/#MC exit path honor the intended CR4 setting, simply check
>> +         * whether the wrong CR4 was in use when the #PF occurred, and exit
>> +         * back to the guest (which will in turn clear the two CR4 bits) to
>> +         * re-execute the instruction. If we get back here, the CR4 bits
>> +         * should then be found clear (unless another NMI/#MC occurred at
>> +         * exactly the right time), and we'll continue processing the
>> +         * exception as normal.
>> +         */



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

  reply	other threads:[~2016-03-09 10:46 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 [this message]
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
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=56DFFEE4.1020008@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.