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: <33166884f54569ab47cc17a4c3e01f9dbc96401a.camel@redhat.com>
Date:   Thu, 20 Aug 2020 13:05:37 +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:01 +0200, Paolo Bonzini wrote:
> On 20/08/20 11:13, Maxim Levitsky wrote:
> > +	u32 clean = nested_vmcb->control.clean;
> > +
> > +	if (svm->nested.vmcb_gpa != vmcb_gpa) {
> > +		svm->nested.vmcb_gpa = vmcb_gpa;
> > +		clean = 0;
> > +	}
> 
> 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).

Best regards,
	Maxim Levitsky

> 
> Paolo
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ