linux-kernel - Re: [PATCH] Fix undefined operation VMXOFF during reboot and crash

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200610214231.GH18790@linux.intel.com>
Date:   Wed, 10 Jun 2020 14:42:31 -0700
From:   Sean Christopherson <sean.j.christopherson@...el.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     "David P. Reed" <dpreed@...pplum.com>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>,
        Allison Randal <allison@...utok.net>,
        Enrico Weigelt <info@...ux.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Kate Stewart <kstewart@...uxfoundation.org>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        Martin Molnar <martin.molnar.programming@...il.com>,
        Andy Lutomirski <luto@...nel.org>,
        Alexandre Chartre <alexandre.chartre@...cle.com>,
        Jann Horn <jannh@...gle.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Fix undefined operation VMXOFF during reboot and crash

Gah, I typed too slow :-)

On Wed, Jun 10, 2020 at 11:34:21PM +0200, Thomas Gleixner wrote:
> We have exception fixups to avoid exactly that kind of horrible
> workarounds all over the place.
> 
> static inline int cpu_vmxoff_safe(void)
> {
>         int err;
>  
> 	asm volatile("2: vmxoff; xor %[err],%[err]\n"
> 		     "1:\n\t"
> 		     ".section .fixup,\"ax\"\n\t"
> 		     "3:  mov %[fault],%[err] ; jmp 1b\n\t"
> 		     ".previous\n\t"
> 		     _ASM_EXTABLE(2b, 3b)
> 		     : [err] "=a" (err)
> 		     : [fault] "i" (-EFAULT)
> 		     : "memory");
>         return err;
> }
> 
> static inline void __cpu_emergency_vmxoff(void)
> {
>         if (!cpu_vmx_enabled())
>         	return;
>         if (!cpu_vmxoff_safe())
>         	cr4_clear_bits(X86_CR4_VMXE);

This bit is wrong, CR4.VMXE should be cleared even if VMXOFF faults, e.g.
if this is called in NMI context and the NMI arrived in KVM code between
VMXOFF and clearing CR4.VMXE.

All other VMXOFF faults are mode related, i.e. any fault is guaranteed to
be due to the !post-VMXON check unless we're magically in RM, VM86, compat
mode, or at CPL>0.

> }
> 
> Problem solved.
> 
> Thanks,
> 
>         tglx