linux-kernel - Re: [PATCH 0/2] KVM: x86: Emulate L2 triple fault without killing L1

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: <YD6BS0PR/+d6iC5Q@google.com>
Date:   Tue, 2 Mar 2021 10:17:47 -0800
From:   Sean Christopherson <seanjc@...gle.com>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>
Subject: Re: [PATCH 0/2] KVM: x86: Emulate L2 triple fault without killing L1

On Tue, Mar 02, 2021, Paolo Bonzini wrote:
> On 02/03/21 18:45, Sean Christopherson wrote:
> > If KVM (L0) intercepts #GP, but L1 does not, then L2 can kill L1 by
> > triggering triple fault.  On both VMX and SVM, if the CPU hits a fault
> > while vectoring an injected #DF (or I supposed any #DF), any intercept
> > from the hypervisor takes priority over triple fault.  #PF is unlikely to
> > be intercepted by L0 but not L1.  The bigger problem is #GP, which is
> > intercepted on both VMX and SVM if enable_vmware_backdoor=1, and is also
> > now intercepted for the lovely VMRUN/VMLOAD/VMSAVE errata.
> > 
> > Based on kvm/queue, commit fe5f0041c026 ("KVM/SVM: Move vmenter.S exception
> > fixups out of line").  x86.c and svm/nested.c conflict with kvm/master.
> > They are minor and straighforward, but let me know if you want me to post
> > a version based on kvm/master for easier inclusion into 5.12.
> 
> I think it would be too intrusive.  Let's stick this in 5.13 only.

Hmm, agreed, especially since most of the paths are not properly tested.  In
that case, probably best to also drop stable@...nel.org?