From: Jiri Slaby <jslaby@suse.cz>
To: "Thomas D." <whissi@whissi.de>,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Cc: "luto@kernel.org" <luto@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH-v3.14.y 3/6] x86/nmi/64: Switch stacks on userspace NMI entry
Date: Tue, 18 Aug 2015 21:32:38 +0200 [thread overview]
Message-ID: <55D38856.5000801@suse.cz> (raw)
In-Reply-To: <55D36763.80609@whissi.de>
On 08/18/2015, 07:12 PM, Thomas D. wrote:
>>> --- a/arch/x86/kernel/entry_64.S
>>> +++ b/arch/x86/kernel/entry_64.S
>>> @@ -1715,19 +1715,88 @@ ENTRY(nmi)
>>> * a nested NMI that updated the copy interrupt stack frame, a
>>> * jump will be made to the repeat_nmi code that will handle the second
>>> * NMI.
>>> + *
>>> + * However, espfix prevents us from directly returning to userspace
>>> + * with a single IRET instruction. Similarly, IRET to user mode
>>> + * can fault. We therefore handle NMIs from user space like
>>> + * other IST entries.
>>> */
>>>
>>> /* Use %rdx as out temp variable throughout */
>>> pushq_cfi %rdx
>>> CFI_REL_OFFSET rdx, 0
>>>
>>> + testb $3, CS-RIP+8(%rsp)
>>> + jz .Lnmi_from_kernel
>>> +
>>> + /*
>>> + * NMI from user mode. We need to run on the thread stack, but we
>>> + * can't go through the normal entry paths: NMIs are masked, and
>>> + * we don't want to enable interrupts, because then we'll end
>>> + * up in an awkward situation in which IRQs are on but NMIs
>>> + * are off.
>>> + */
>>> +
>>> + SWAPGS
>>> + cld
>>> + movq %rsp, %rdx
>>> + movq PER_CPU_VAR(kernel_stack), %rsp
>>
>> I think you are wasting stack space here. With kernel_stack, you should
>> add 5*8 (KERNEL_STACK_OFFSET) to the pointer here. I.e. space for 5
>> registers is pre-reserved at kernel_stack already. (Or use movq instead
>> of the 5 pushq below.)
>>
>> Why don't you re-use the 3.16's version anyway?
>>
>>> + pushq 5*8(%rdx) /* pt_regs->ss */
>>> + pushq 4*8(%rdx) /* pt_regs->rsp */
>>> + pushq 3*8(%rdx) /* pt_regs->flags */
>>> + pushq 2*8(%rdx) /* pt_regs->cs */
>>> + pushq 1*8(%rdx) /* pt_regs->rip */
>>> + pushq $-1 /* pt_regs->orig_ax */
>>> + pushq %rdi /* pt_regs->di */
>>> + pushq %rsi /* pt_regs->si */
>>> + pushq (%rdx) /* pt_regs->dx */
>>> + pushq %rcx /* pt_regs->cx */
>>> + pushq %rax /* pt_regs->ax */
>>> + pushq %r8 /* pt_regs->r8 */
>>> + pushq %r9 /* pt_regs->r9 */
>>> + pushq %r10 /* pt_regs->r10 */
>>> + pushq %r11 /* pt_regs->r11 */
>>> + pushq %rbx /* pt_regs->rbx */
>>> + pushq %rbp /* pt_regs->rbp */
>>> + pushq %r12 /* pt_regs->r12 */
>>> + pushq %r13 /* pt_regs->r13 */
>>> + pushq %r14 /* pt_regs->r14 */
>>> + pushq %r15 /* pt_regs->r15 */
>
> Mh, so you mean
>
>> + addq $KERNEL_STACK_OFFSET, %rsp
>
> between
>
>> + movq PER_CPU_VAR(kernel_stack), %rsp
>
> and
>
>> + pushq 5*8(%rdx) /* pt_regs->ss */
>
> is missing?
Yep, that makes sense. But I am not an x86 maintainer :P.
--
js
suse labs
next prev parent reply other threads:[~2015-08-18 19:32 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-17 10:39 Request for stable 3.18.y and 3.14.y inclusion: Fix for CVE-2015-3290 (nmi) Thomas D.
2015-08-17 13:23 ` Greg KH
2015-08-17 22:55 ` [PATCH-v3.14.y 0/6] x86/nmi/64: Stable backports for CVE-2015-3290 and CVE-2015-5157 Thomas D
2015-08-17 22:55 ` [PATCH-v3.14.y 1/6] x86/nmi: Enable nested do_nmi() handling for 64-bit kernels Thomas D
2015-08-17 22:55 ` [PATCH-v3.14.y 2/6] x86/nmi/64: Remove asm code that saves CR2 Thomas D
2015-08-17 22:55 ` [PATCH-v3.14.y 3/6] x86/nmi/64: Switch stacks on userspace NMI entry Thomas D
2015-08-18 15:45 ` Jiri Slaby
2015-08-18 17:12 ` Thomas D.
2015-08-18 19:32 ` Jiri Slaby [this message]
2015-08-19 14:11 ` [PATCH-v3.14.y v2 0/6] x86/nmi/64: Stable backports for CVE-2015-3290 and CVE-2015-5157 Thomas D
2015-08-19 14:11 ` [PATCH-v3.14.y v2 1/6] x86/nmi: Enable nested do_nmi() handling for 64-bit kernels Thomas D
2015-09-29 13:38 ` Greg KH
2015-08-19 14:11 ` [PATCH-v3.14.y v2 2/6] x86/nmi/64: Remove asm code that saves CR2 Thomas D
2015-08-19 14:11 ` [PATCH-v3.14.y v2 3/6] x86/nmi/64: Switch stacks on userspace NMI entry Thomas D
2015-08-19 14:11 ` [PATCH-v3.14.y v2 4/6] x86/nmi/64: Improve nested NMI comments Thomas D
2015-08-19 14:11 ` [PATCH-v3.14.y v2 5/6] x86/nmi/64: Reorder nested NMI checks Thomas D
2015-08-19 14:11 ` [PATCH-v3.14.y v2 6/6] x86/nmi/64: Use DF to avoid userspace RSP confusing nested NMI detection Thomas D
2015-09-29 14:11 ` [PATCH-v3.14.y v2 0/6] x86/nmi/64: Stable backports for CVE-2015-3290 and CVE-2015-5157 Greg KH
2015-08-17 22:55 ` [PATCH-v3.14.y 4/6] x86/nmi/64: Improve nested NMI comments Thomas D
2015-08-17 22:55 ` [PATCH-v3.14.y 5/6] x86/nmi/64: Reorder nested NMI checks Thomas D
2015-08-17 22:55 ` [PATCH-v3.14.y 6/6] x86/nmi/64: Use DF to avoid userspace RSP confusing nested NMI detection Thomas D
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=55D38856.5000801@suse.cz \
--to=jslaby@suse.cz \
--cc=gregkh@linuxfoundation.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=whissi@whissi.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;
as well as URLs for NNTP newsgroup(s).