linux-kernel - Re: [PATCH 1/4] KVM: svm: prevent MWAIT in guest with erratum 400

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: <20170503201134.fabwojfrqkhime7c@pd.tnic>
Date:   Wed, 3 May 2017 22:11:34 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Radim Krčmář <rkrcmar@...hat.com>
Cc:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        Paolo Bonzini <pbonzini@...hat.com>,
        Alexander Graf <agraf@...e.de>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        "Gabriel L. Somlo" <gsomlo@...il.com>
Subject: Re: [PATCH 1/4] KVM: svm: prevent MWAIT in guest with erratum 400

On Wed, May 03, 2017 at 09:37:30PM +0200, Radim Krčmář wrote:
> The host might miss APIC timer interrupts if the guest enters a specific
> C-state.  Quoting the erratum:
> 
>   400 APIC Timer Interrupt Does Not Occur in Processor C-States
> 
>   Description
> 
>   An APIC timer interrupt that becomes pending in low-power states C1E
>   or C3 will not cause the processor to enter the C0 state even if the
>   interrupt is enabled by Timer Local Vector Table Entry[Mask],
>   APIC320[16]). APIC timer functionality is otherwise unaffected.
> 
>   Potential Effect on System
> 
>   System hang may occur provided that the operating system has not
>   configured another interrupt source.  APIC timer interrupts may be
>   delayed or, when the APIC timer is configured in rollover mode
>   (APIC320[17]), the APIC timer may roll over multiple times in the
>   low-power state with only one interrupt presented after the processor
>   resumes. The standard use of the APIC timer does not make this effect
>   significant.
> 
> Signed-off-by: Radim Krčmář <rkrcmar@...hat.com>
> ---
>  arch/x86/kvm/x86.h | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h
> index 612067074905..3ed7dd8737ab 100644
> --- a/arch/x86/kvm/x86.h
> +++ b/arch/x86/kvm/x86.h
> @@ -223,8 +223,7 @@ static inline bool kvm_mwait_in_guest(void)
>  
>  	switch (boot_cpu_data.x86_vendor) {
>  	case X86_VENDOR_AMD:
> -		/* All AMD CPUs have a working MWAIT implementation */
> -		return true;
> +		return !boot_cpu_has_bug(X86_BUG_AMD_E400);

Well, this looks wrong: it is X86_BUG_AMD_APIC_C1E, which actually
denotes that we must enable the E400 workaround because the platform
actually goes into C1E.

X86_BUG_AMD_E400 gets set only on the affected f/m/s range but if the
BIOS doesn't put the CPU in C1E, we don't hit the erratum and all is
peachy.

Also, what do APIC timer interrupts even have to do with MWAIT-ing in
the guest, especially if we enable the workaround and switch to HPET on
the host? Maybe I'm missing something here...

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.