x86: Don't ENABLE_IBRS in nmi when we are still running on user cr3

It won't end well - especially as we need to be careful about
touching kernel variables and can only do that in the kernel cr3.

The code:
        movq    PER_CPU_VAR(cpu_current_top_of_stack), %rsp

may lead one to believe you can access kernel variables, but in fact
we haven't yet switched over the kernel cr3.

Orabug: 27344012
CVE: CVE-2017-5715

Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com>

diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 40970c5403b8e0818310b9b4b4615894d52f3f33..d2684f7bd8d95a24bc5229684f1647a2d7e0390a 100644 (file)
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -1717,7 +1717,6 @@ ENTRY(nmi)
        cld
        movq    %rsp, %rdx
        movq    PER_CPU_VAR(cpu_current_top_of_stack), %rsp
-       ENABLE_IBRS
        pushq   5*8(%rdx)       /* pt_regs->ss */
        pushq   4*8(%rdx)       /* pt_regs->rsp */
        pushq   3*8(%rdx)       /* pt_regs->flags */
@@ -1759,6 +1758,7 @@ ENTRY(nmi)
        movq    %rax, %cr3
 2:
 #endif
+       ENABLE_IBRS
        call    do_nmi
        DISABLE_IBRS
 #ifdef CONFIG_PAGE_TABLE_ISOLATION