linux-kernel - Re: [PATCH 2/3 V7] KVM, SEV: Add support for SEV-ES intra host migration

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:   Fri, 10 Sep 2021 00:50:42 +0000
From:   Sean Christopherson <seanjc@...gle.com>
To:     Peter Gonda <pgonda@...gle.com>
Cc:     kvm@...r.kernel.org, Marc Orr <marcorr@...gle.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        David Rientjes <rientjes@...gle.com>,
        "Dr . David Alan Gilbert" <dgilbert@...hat.com>,
        Brijesh Singh <brijesh.singh@....com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3 V7] KVM, SEV: Add support for SEV-ES intra host
 migration

On Thu, Sep 02, 2021, Peter Gonda wrote:
> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index 8db666a362d4..fac21a82e4de 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -1545,6 +1545,59 @@ static void migrate_info_from(struct kvm_sev_info *dst,
>  	list_replace_init(&src->regions_list, &dst->regions_list);
>  }
>  
> +static int migrate_vmsa_from(struct kvm *dst, struct kvm *src)
> +{
> +	int i, num_vcpus;
> +	struct kvm_vcpu *dst_vcpu, *src_vcpu;
> +	struct vcpu_svm *dst_svm, *src_svm;
> +
> +	num_vcpus = atomic_read(&dst->online_vcpus);
> +	if (num_vcpus != atomic_read(&src->online_vcpus)) {
> +		pr_warn_ratelimited(
> +			"Source and target VMs must have same number of vCPUs.\n");

Same comments about not logging the why.

> +		return -EINVAL;
> +	}
> +
> +	for (i = 0; i < num_vcpus; ++i) 
> +		src_vcpu = src->vcpus[i];

This can be:

	kvm_for_each_vcpu(i, src_vcpu, src) {
		if (!src_vcpu->arch.guest_state_protected)
			return -EINVAL;

	}
> +		if (!src_vcpu->arch.guest_state_protected) {
> +			pr_warn_ratelimited(
> +				"Source ES VM vCPUs must have protected state.\n");
> +			return -EINVAL;
> +		}
> +	}
> +
> +	for (i = 0; i < num_vcpus; ++i) {

And again here,

	kvm_for_each_vcpu(i, src_vcpu, src) {
		src_svm = to_svm(src_vcpu);

> +		src_vcpu = src->vcpus[i];
> +		src_svm = to_svm(src_vcpu);
> +		dst_vcpu = dst->vcpus[i];

Probably a good idea to use kvm_get_vcpu(), even though dst->lock is held.  If
nothing else, using kvm_get_vcpu() may save some merge pain as there's a proposal
to switch vcpus to an xarray.

> +		dst_svm = to_svm(dst_vcpu);
> +
> +		/*
> +		 * Copy VMSA and GHCB fields from the source to the destination.
> +		 * Clear them on the source to prevent the VM running and

As brought up in the prior patch, clearing the fields might ensure future KVM_RUNs
fail, but it doesn't prevent the VM from running _now_.  And with vcpu->mutext
held, I think a more appropriate comment would be:

		/*
		 * Transfer VMSA and GHCB state to the destination.  Nullify and
		 * clear source fields as appropriate, the state now belongs to
		 * the destination.
		 */

> +		 * changing the state of the VMSA/GHCB unexpectedly.
> +		 */
> +		dst_vcpu->vcpu_id = src_vcpu->vcpu_id;
> +		dst_svm->vmsa = src_svm->vmsa;
> +		src_svm->vmsa = NULL;
> +		dst_svm->ghcb = src_svm->ghcb;
> +		src_svm->ghcb = NULL;
> +		dst_svm->vmcb->control.ghcb_gpa =
> +				src_svm->vmcb->control.ghcb_gpa;

Let this poke out, an 83 char line isn't the end of the world, and not having
the interrupt makes the code more readable overall.

> +		src_svm->vmcb->control.ghcb_gpa = 0;

Nit, '0' isn't an invalid GPA.  The reset value would be more appropriate, though
I would just leave this alone.

> +		dst_svm->ghcb_sa = src_svm->ghcb_sa;
> +		src_svm->ghcb_sa = NULL;
> +		dst_svm->ghcb_sa_len = src_svm->ghcb_sa_len;
> +		src_svm->ghcb_sa_len = 0;
> +		dst_svm->ghcb_sa_sync = src_svm->ghcb_sa_sync;
> +		src_svm->ghcb_sa_sync = false;
> +		dst_svm->ghcb_sa_free = src_svm->ghcb_sa_free;
> +		src_svm->ghcb_sa_free = false;
> +	}
> +	return 0;
> +}