linux-kernel - Re: [PATCH 3/4] KVM: x86: drop bogus MWAIT check

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: <20170504212650-mutt-send-email-mst@kernel.org>
Date:   Thu, 4 May 2017 21:29:49 +0300
From:   "Michael S. Tsirkin" <mst@...hat.com>
To:     Radim Krčmář <rkrcmar@...hat.com>
Cc:     Paolo Bonzini <pbonzini@...hat.com>, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org, Alexander Graf <agraf@...e.de>,
        "Gabriel L. Somlo" <gsomlo@...il.com>
Subject: Re: [PATCH 3/4] KVM: x86: drop bogus MWAIT check

On Thu, May 04, 2017 at 04:33:28PM +0200, Radim Krčmář wrote:
> 2017-05-04 12:58+0200, Paolo Bonzini:
> > On 03/05/2017 21:37, Radim Krčmář wrote:
> >> The guest can call MWAIT with ECX = 0 even if we enforce
> >> CPUID5_ECX_INTERRUPT_BREAK;  the call would have the exactly the same
> >> effect as if the host didn't have CPUID5_ECX_INTERRUPT_BREAK.
> >> 
> >> The check was added in some iteration while trying to fix a reported
> >> OS X on Core 2 bug, but the CPU had CPUID5_ECX_INTERRUPT_BREAK and the
> >> bug is elsewhere.
> > 
> > The reason for this, as I understood it, is that we have historically
> > not published leaf 5 information via KVM_GET_SUPPORTED_CPUID.  For this
> > reason, QEMU is publishing CPUID5_ECX_INTERRUPT_BREAK.  Then if:
> 
> I see, it was added to QEMU in e737b32a3688 ("Core 2 Duo specification
> (Alexander Graf)").
> 
> > - the host doesn't have ECX[0]=1 support
> > 
> > - the guest sets ECX[0]
> > 
> > you get a #GP in the guest.  So wrong comment but right thing to do.
> 
> That userspace didn't set CPUID.01H:ECX.MONITOR[bit 3], so a guest
> should get #UD instead, but MWAIT couldn't be expected to work.
> 
> I think that the guest bug is very unlikely, so I'd get rid of the
> condition anyway ... we have also recently killed support for pre-Core 2
> hosts and AFAIK, all newer Intels have it.

That's a strange approach.  If other software followed the same logic,
it would say all newer intels have MWAIT support without
checking the MWAIT leaf :)

> (Not so sure about AMDs, which share the same problem, so we do need to
>  do more than just comment it better in any case.)
-- 
MST