xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: "Wu, Feng" <feng.wu@intel.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"Dong, Eddie" <eddie.dong@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>
Subject: Re: [PATCH v2 2/7] Clear AC bit in RFLAGS to protect Xen itself by SMAP
Date: Thu, 24 Apr 2014 11:51:12 +0100	[thread overview]
Message-ID: <5358ECA0.9000204@citrix.com> (raw)
In-Reply-To: <E959C4978C3B6342920538CF579893F001F39998@SHSMSX104.ccr.corp.intel.com>

On 24/04/14 08:20, Wu, Feng wrote:
>
>> -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Thursday, April 24, 2014 3:19 PM
>> To: Wu, Feng
>> Cc: Andrew Cooper; ian.campbell@citrix.com; Dong, Eddie; Nakajima, Jun; Tian,
>> Kevin; xen-devel@lists.xen.org
>> Subject: RE: [PATCH v2 2/7] Clear AC bit in RFLAGS to protect Xen itself by SMAP
>>
>>>>> On 24.04.14 at 08:45, <feng.wu@intel.com> wrote:
>>>> From: Andrew Cooper [mailto:andrew.cooper3@citrix.com]
>>>> On 23/04/14 15:35, Feng Wu wrote:
>>>>> --- a/xen/arch/x86/x86_64/entry.S
>>>>> +++ b/xen/arch/x86/x86_64/entry.S
>>>>> @@ -120,6 +120,7 @@ restore_all_xen:
>>>>>   * the space left by the trampoline.
>>>>>   */
>>>>>  ENTRY(syscall_enter)
>>>>> +        ASM_CLAC
>>>> Surely this can be sorted more succinctly by setting X86_EFLAGS_AC in
>>>> MSR 0xc0000084 ?
>>> Okay.
>>>
>>>> You also need to patch the entry points in the compat trampoline in
>>> The MSR_SYSCALL_MASK is common in long mode and compat mode, right?
>>> Seems no need to do anything else for compat mode.
>> The same stub is being written there twice, just with different CS
>> selectors, and both are behind that EFLAGS masking MSR. So I'm not
>> sure what Andrew's apparently incomplete sentence was actually
>> intended to mean.
> Yes, that is also my understanding.

It was my mistake - I got the sysenter and syscall entry points confused
given a brief look at the code yesterday.  On more careful review it is
currently fine.

>
>>>>> @@ -268,6 +269,7 @@ bad_hypercall:
>>>>>          jmp  test_all_events
>>>>>
>>>>>  ENTRY(sysenter_entry)
>>>>> +        ASM_CLAC
>>>>>          sti
>>>>>          pushq $FLAT_USER_SS
>>>>>          pushq $0
>> Looking at this again, btw, makes me thing that the clac should go
>> after the sti here.

It must be after sysenter_eflags_saved, or we will erroneously clear the
AC flag from the flags used to restore guest context.

>>
>>>>> @@ -309,6 +311,7 @@ UNLIKELY_END(sysenter_gpf)
>>>>>          jmp   .Lbounce_exception
>>>>>
>>>> ...
>>>>>          .pushsection .init.text, "ax", @progbits
>>>>>  ENTRY(early_page_fault)
>>>>> +        ASM_CLAC
>>>> I don't think CLAC is appropriate here.  This is a pagefault handler for
>>>> Xen early boot, and is replaced with a real handler substantially before
>>>> dom0 is created.
>>> Adding CLAC here is not so useful, but harmful neither. If you think it
>>> should be removed, I will do that in the next post.
>> Yes, let's not scatter it around pointlessly (even more so now that
>> you plan on enabling SMAP only after having built Dom0).
>>
>>>>> @@ -689,6 +714,7 @@ ENTRY(enable_nmis)
>>>>>
>>>>>  /* No op trap handler.  Required for kexec crash path. */
>>>>>  GLOBAL(trap_nop)
>>>>> +        ASM_CLAC
>>>>>          iretq
>>>> This is not sensible in the slightest, given the following instruction.
>>> The same comments as early_page_fault case.
>> The situation is different here, but the addition indeed doesn't seem
>> to make sense.

The handler is used to prevent NMIs and MCEs getting in the way of the
crash path.  Slowing down the return to the crash path is counter
productive in all cases.

~Andrew

  reply	other threads:[~2014-04-24 10:51 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-23 14:35 [PATCH v2 2/7] Clear AC bit in RFLAGS to protect Xen itself by SMAP Feng Wu
2014-04-23 10:19 ` Andrew Cooper
2014-04-24  6:45   ` Wu, Feng
2014-04-24  7:19     ` Jan Beulich
2014-04-24  7:20       ` Wu, Feng
2014-04-24 10:51         ` Andrew Cooper [this message]
2014-04-24 11:37           ` Jan Beulich
2014-04-25  2:02             ` Wu, Feng
2014-04-25  2:10           ` Wu, Feng
2014-04-23 10:30 ` 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=5358ECA0.9000204@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=eddie.dong@intel.com \
    --cc=feng.wu@intel.com \
    --cc=ian.campbell@citrix.com \
    --cc=jun.nakajima@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=xen-devel@lists.xen.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).