From: "Jan Beulich" <JBeulich@suse.com>
To: "Steven Rostedt" <srostedt@redhat.com>
Cc: <mingo@elte.hu>, "Steven Rostedt" <rostedt@goodmis.org>,
<tglx@linutronix.de>, <linux-kernel@vger.kernel.org>,
<hpa@zytor.com>
Subject: Re: [PATCH] x86-64: fix CFI annotations for NMI nesting code
Date: Fri, 24 Feb 2012 14:36:29 +0000 [thread overview]
Message-ID: <4F47AE7D0200007800074ABB@nat28.tlf.novell.com> (raw)
In-Reply-To: <1330092690.3306.18.camel@fedora>
>>> On 24.02.12 at 15:11, Steven Rostedt <srostedt@redhat.com> wrote:
> On Fri, 2012-02-24 at 12:06 +0000, Jan Beulich wrote:
>> /* Make another copy, this one may be modified by nested NMIs */
>> .rept 5
>> pushq_cfi 4*8(%rsp)
>
> Half way through this copy (the rept is not atomic) we get an NMI, it
> sees that we are nested so it updates this copy of the interrupt frame
> and returns. Now the rest of the copy finishes so we end up with a half
> and half stack frame (half to go back to restart_nmi and half to go back
> to the original location of the stack). The result is a system crash.
>
> But! There is a fix to this. We can move the setting of the special
> variable to here and make this the "repeart_nmi" instead. The nested NMI
> checks that we are not in the repeat nmi before updating the stack. If
> it interrupted in the repeat nmi it will just return knowing a repeat is
> about to take place anyway.
>
>
> So instead of adding restart_nmi here, add:
>
> repeat_nmi:
> /* Update the stack variable to say we are in NMI */
> movq $1, 5*8(%rsp)
>
> /* Make another copy, this one may be modified by nested NMIs */
> .rept 5
> pushq_cfi 4*8(%rsp)
> end_repeat_nmi:
>
>
> And just continue. We only need to protect against updating the stack
> and the nested NMI will not touch it if it interrupted RIP is between
> repeat_nmi and end_repeat_nmi. But there's no reason that we can't just
> set the iret jump to go back into the middle of the NMI handler.
>
> Would that work for you?
Of course, thanks for spotting this oversight of mine. I assume you
meant the end_repeat_nmi to go after the .endr though, not before.
I'll get a fixed patch sent out soon.
Jan
> Also we need to add a comment about this. Just above the repeat_nmi:
>
> /*
> * If there was a nested NMI, the first NMI's iret will return
> * here. But NMIs are still enabled and we can take another
> * nested NMI. The nested NMI checks the interrupted RIP to see
> * if it is between repeat_nmi and end_repeat_nmi, and if so
> * it will just return, as we are about to repeat an NMI anyway.
> * This makes it safe to copy to the stack frame that a nested
> * NMI will update.
> */
>
>
> -- Steve
>
>> .endr
>> -
>> - /* Do not pop rdx, nested NMIs will corrupt it */
>> - movq 11*8(%rsp), %rdx
>> + CFI_DEF_CFA_OFFSET SS+8-RIP
>>
>> /*
>> * Everything below this point can be preempted by a nested
>> @@ -1639,7 +1647,6 @@ first_nmi:
>> * caused by an exception and nested NMI will start here, and
>> * can still be preempted by another NMI.
>> */
>> -restart_nmi:
>> pushq_cfi $-1 /* ORIG_RAX: no syscall to restart */
>> subq $ORIG_RAX-R15, %rsp
>> CFI_ADJUST_CFA_OFFSET ORIG_RAX-R15
>> @@ -1665,8 +1672,6 @@ nmi_restore:
>> /* Clear the NMI executing stack variable */
>> movq $0, 10*8(%rsp)
>> jmp irq_return
>> - CFI_ENDPROC
>> -END(nmi)
>>
>> /*
>> * If an NMI hit an iret because of an exception or breakpoint,
>> @@ -1675,18 +1680,12 @@ END(nmi)
>> * stack to jump to here when it does the final iret.
>> */
>> repeat_nmi:
>> - INTR_FRAME
>> /* Update the stack variable to say we are still in NMI */
>> movq $1, 5*8(%rsp)
>> -
>> - /* copy the saved stack back to copy stack */
>> - .rept 5
>> - pushq_cfi 4*8(%rsp)
>> - .endr
>> -
>> jmp restart_nmi
>> - CFI_ENDPROC
>> end_repeat_nmi:
>> + CFI_ENDPROC
>> +END(nmi)
>>
>> ENTRY(ignore_sysret)
>> CFI_STARTPROC
>>
>>
>>
next prev parent reply other threads:[~2012-02-24 14:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-24 12:06 Jan Beulich
2012-02-24 14:11 ` Steven Rostedt
2012-02-24 14:36 ` Jan Beulich [this message]
2012-02-24 14:44 ` Steven Rostedt
2012-02-28 10:37 ` [tip:x86/asm] x86-64: Fix " tip-bot for 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=4F47AE7D0200007800074ABB@nat28.tlf.novell.com \
--to=jbeulich@suse.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=srostedt@redhat.com \
--cc=tglx@linutronix.de \
/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
all inboxes | Powered by JetHome®