linux-kernel - Re: [PATCH 8/8] KVM: nSVM: read only changed fields of the nested guest data area

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 for Android: free password hash cracker in your pocket

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

Message-ID: <76c13e7d8f3c26583411fc6d42f50c98e92ebc1c.camel@redhat.com>
Date:   Thu, 20 Aug 2020 13:26:57 +0300
From:   Maxim Levitsky <mlevitsk@...hat.com>
To:     Paolo Bonzini <pbonzini@...hat.com>, kvm@...r.kernel.org
Cc:     Jim Mattson <jmattson@...gle.com>, Joerg Roedel <joro@...tes.org>,
        Borislav Petkov <bp@...en8.de>,
        Thomas Gleixner <tglx@...utronix.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        "open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" 
        <linux-kernel@...r.kernel.org>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
        Ingo Molnar <mingo@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Sean Christopherson <sean.j.christopherson@...el.com>
Subject: Re: [PATCH 8/8] KVM: nSVM: read only changed fields of the nested
 guest data area

On Thu, 2020-08-20 at 12:18 +0200, Paolo Bonzini wrote:
> On 20/08/20 12:05, Maxim Levitsky wrote:
> > > You probably should set clean to 0 also if the guest doesn't have the
> > > VMCBCLEAN feature (so, you first need an extra patch to add the
> > > VMCBCLEAN feature to cpufeatures.h).  It's probably best to cache the
> > > guest vmcbclean in struct vcpu_svm, too.
> > Right, I totally forgot about this one.
> > 
> > One thing why I made this patch optional, is that I can instead drop it,
> > and not 'read back' the saved area on vmexit, this will probably be faster
> > that what this optimization does. What do you think? Is this patch worth it?
> > (I submitted it because I already implemented this and wanted to hear opinion
> > on this).
> 
> Yeah, good point.  It's one copy either way, either on vmexit (and
> partly on vmentry depending on clean bits) or on vmentry.  I had not
> considered the need to copy from vmcb02 to the cached vmcb12 on vmexit. :(
> 
> Let's shelve this for a bit, and revisit it once we have separate vmcb01
> and vmcb02.  Then we might still use the clean bits to avoid copying
> data from vmcb12 to vmcb02, including avoiding consistency checks
> because we know the vmcb02 data is legit.
It makes sense I guess. The vmcb02 would then play the role of the cache of
vmcb12

> 
> Patches 1-5 are still worthwhile, so you can clean them up and send them.
> 
> Paolo

OK, on it now.

Best regards,
	Maxim Levitsky
>