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]
Date:   Mon, 24 May 2021 15:35:30 +0300
From:   Maxim Levitsky <mlevitsk@...hat.com>
To:     Vitaly Kuznetsov <vkuznets@...hat.com>, kvm@...r.kernel.org,
        Paolo Bonzini <pbonzini@...hat.com>
Cc:     Sean Christopherson <seanjc@...gle.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 6/7] KVM: nVMX: Request to sync eVMCS from VMCS12
 after migration

On Mon, 2021-05-17 at 15:50 +0200, Vitaly Kuznetsov wrote:
> VMCS12 is used to keep the authoritative state during nested state
> migration. In case 'need_vmcs12_to_shadow_sync' flag is set, we're
> in between L2->L1 vmexit and L1 guest run when actual sync to
> enlightened (or shadow) VMCS happens. Nested state, however, has
> no flag for 'need_vmcs12_to_shadow_sync' so vmx_set_nested_state()->
> set_current_vmptr() always sets it. Enlightened vmptrld path, however,
> doesn't have the quirk so some VMCS12 changes may not get properly
> reflected to eVMCS and L1 will see an incorrect state.
> 
> Note, during L2 execution or when need_vmcs12_to_shadow_sync is not
> set the change is effectively a nop: in the former case all changes
> will get reflected during the first L2->L1 vmexit and in the later
> case VMCS12 and eVMCS are already in sync (thanks to
> copy_enlightened_to_vmcs12() in vmx_get_nested_state()).
> 
> Signed-off-by: Vitaly Kuznetsov <vkuznets@...hat.com>
> ---
>  arch/x86/kvm/vmx/nested.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
> index 3bfbf991bf45..a0dedd413a23 100644
> --- a/arch/x86/kvm/vmx/nested.c
> +++ b/arch/x86/kvm/vmx/nested.c
> @@ -3127,6 +3127,12 @@ static bool nested_get_evmcs_page(struct kvm_vcpu *vcpu)
>  		if (evmptrld_status == EVMPTRLD_VMFAIL ||
>  		    evmptrld_status == EVMPTRLD_ERROR)
>  			return false;
> +
> +		/*
> +		 * Post migration VMCS12 always provides the most actual
> +		 * information, copy it to eVMCS upon entry.
> +		 */
> +		vmx->nested.need_vmcs12_to_shadow_sync = true;

I noticed that bug too while reviewing the previous patches, 
wasted some time thinking about it :-(

This does look like a clean and correct way to fix this, unless
you adopt my suggestion to sync evmcs right away on nested vmexit
as I explained in my review of patch 3 of this series.

Reviewed-by: Maxim Levitsky <mlevitsk@...hat.com>

Best regards,
	Maxim Levitsky

>  	}
>  
>  	return true;




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ