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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Tue, 5 May 2020 20:32:48 -0700
From:   Sean Christopherson <>
To:     Qian Cai <>
Cc:     Paolo Bonzini <>, KVM <>,
        LKML <>
Subject: Re: Intel KVM entry failed, hardware error 0x0

On Tue, May 05, 2020 at 08:00:15PM -0700, Sean Christopherson wrote:
> On Tue, May 05, 2020 at 10:32:15PM -0400, Qian Cai wrote:
> > Today’s linux-next started to fail with this config,
> > 
> >
> > 
> > qemu-kvm-2.12.0-99.module+el8.2.0+5827+8c39933c.x86_64
> > 
> > I believe it was working yesterday. Before I bury myself bisecting it, does
> > anyone have any thought?
> It reproduces for me as well with my vanilla config in a VM.  I can debug
> and/or bisect, should be quite quick in a VM.
> VM is bailing on the EPT Violation at the reset vector, i.e. on the very
> first exit.  Presumably KVM is incorrectly setting vmx->fail somewhere.

The __FILL_RETURN_BUFFER in the VM-Exit path was recently modified and
changed how it clobbered EFLAGS, which causes KVM to think VM-Enter failed.
Commit 089dd8e53126 ("x86/speculation: Change FILL_RETURN_BUFFER to work
with objtool") introduced the change, but this is really a bug in KVM.  The
VM-Exit path shouldn't rely on __FILL_RETURN_BUFFER to set EFLAGS to a
specific state, i.e. EFLAGS was always being clobbered, it just happened to
work before now.

I'll get a patch sent out shortly.

Powered by blists - more mailing lists