linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tom Lendacky <thomas.lendacky@amd.com>
To: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
	Sean Christopherson <sean.j.christopherson@intel.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Borislav Petkov <bp@alien8.de>, Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Brijesh Singh <brijesh.singh@amd.com>
Subject: [RFC PATCH v2 33/33] KVM: SVM: Provide support to launch and run an SEV-ES guest
Date: Fri,  2 Oct 2020 12:02:57 -0500	[thread overview]
Message-ID: <aa7c1443b61df6ab2d3b5f4deeaf9e9925b65469.1601658176.git.thomas.lendacky@amd.com> (raw)
In-Reply-To: <cover.1601658176.git.thomas.lendacky@amd.com>

From: Tom Lendacky <thomas.lendacky@amd.com>

An SEV-ES guest is started by invoking a new SEV initialization ioctl,
KVM_SEV_ES_INIT. This identifies the guest as an SEV-ES guest, which is
used to drive the appropriate ASID allocation, VMSA encryption, etc.

Before being able to run an SEV-ES vCPU, the vCPU VMSA must be encrypted
and measured. This is done using the LAUNCH_UPDATE_VMSA command after all
calls to LAUNCH_UPDATE_DATA have been performed, but before LAUNCH_MEASURE
has been performed. In order to establish the encrypted VMSA, the current
(traditional) VMSA and the GPRs are synced to the page that will hold the
encrypted VMSA and then LAUNCH_UPDATE_VMSA is invoked. The vCPU is then
marked as having protected guest state.

Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
 arch/x86/kvm/svm/sev.c | 104 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 104 insertions(+)

diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 6be4f0cbf09d..db8ccb3270f2 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -202,6 +202,16 @@ static int sev_guest_init(struct kvm *kvm, struct kvm_sev_cmd *argp)
 	return ret;
 }
 
+static int sev_es_guest_init(struct kvm *kvm, struct kvm_sev_cmd *argp)
+{
+	if (!sev_es)
+		return -ENOTTY;
+
+	to_kvm_svm(kvm)->sev_info.es_active = true;
+
+	return sev_guest_init(kvm, argp);
+}
+
 static int sev_bind_asid(struct kvm *kvm, unsigned int handle, int *error)
 {
 	struct sev_data_activate *data;
@@ -500,6 +510,94 @@ static int sev_launch_update_data(struct kvm *kvm, struct kvm_sev_cmd *argp)
 	return ret;
 }
 
+static int sev_es_sync_vmsa(struct vcpu_svm *svm)
+{
+	struct vmcb_save_area *save = &svm->vmcb->save;
+
+	/* Check some debug related fields before encrypting the VMSA */
+	if (svm->vcpu.guest_debug || (save->dr7 & ~DR7_FIXED_1))
+		return -EINVAL;
+
+	/* Sync registgers */
+	save->rax = svm->vcpu.arch.regs[VCPU_REGS_RAX];
+	save->rbx = svm->vcpu.arch.regs[VCPU_REGS_RBX];
+	save->rcx = svm->vcpu.arch.regs[VCPU_REGS_RCX];
+	save->rdx = svm->vcpu.arch.regs[VCPU_REGS_RDX];
+	save->rsp = svm->vcpu.arch.regs[VCPU_REGS_RSP];
+	save->rbp = svm->vcpu.arch.regs[VCPU_REGS_RBP];
+	save->rsi = svm->vcpu.arch.regs[VCPU_REGS_RSI];
+	save->rdi = svm->vcpu.arch.regs[VCPU_REGS_RDI];
+	save->r8  = svm->vcpu.arch.regs[VCPU_REGS_R8];
+	save->r9  = svm->vcpu.arch.regs[VCPU_REGS_R9];
+	save->r10 = svm->vcpu.arch.regs[VCPU_REGS_R10];
+	save->r11 = svm->vcpu.arch.regs[VCPU_REGS_R11];
+	save->r12 = svm->vcpu.arch.regs[VCPU_REGS_R12];
+	save->r13 = svm->vcpu.arch.regs[VCPU_REGS_R13];
+	save->r14 = svm->vcpu.arch.regs[VCPU_REGS_R14];
+	save->r15 = svm->vcpu.arch.regs[VCPU_REGS_R15];
+	save->rip = svm->vcpu.arch.regs[VCPU_REGS_RIP];
+
+	/* Sync some non-GPR registers before encrypting */
+	save->xcr0 = svm->vcpu.arch.xcr0;
+	save->pkru = svm->vcpu.arch.pkru;
+	save->xss  = svm->vcpu.arch.ia32_xss;
+
+	/*
+	 * SEV-ES will use a VMSA that is pointed to by the VMCB, not
+	 * the traditional VMSA that is part of the VMCB. Copy the
+	 * traditional VMSA as it has been built so far (in prep
+	 * for LAUNCH_UPDATE_VMSA) to be the initial SEV-ES state.
+	 */
+	memcpy(svm->vmsa, save, sizeof(*save));
+
+	return 0;
+}
+
+static int sev_launch_update_vmsa(struct kvm *kvm, struct kvm_sev_cmd *argp)
+{
+	struct kvm_sev_info *sev = &to_kvm_svm(kvm)->sev_info;
+	struct sev_data_launch_update_vmsa *vmsa;
+	int i, ret;
+
+	if (!sev_es_guest(kvm))
+		return -ENOTTY;
+
+	vmsa = kzalloc(sizeof(*vmsa), GFP_KERNEL);
+	if (!vmsa)
+		return -ENOMEM;
+
+	for (i = 0; i < kvm->created_vcpus; i++) {
+		struct vcpu_svm *svm = to_svm(kvm->vcpus[i]);
+
+		/* Perform some pre-encryption checks against the VMSA */
+		ret = sev_es_sync_vmsa(svm);
+		if (ret)
+			goto e_free;
+
+		/*
+		 * The LAUNCH_UPDATE_VMSA command will perform in-place
+		 * encryption of the VMSA memory content (i.e it will write
+		 * the same memory region with the guest's key), so invalidate
+		 * it first.
+		 */
+		clflush_cache_range(svm->vmsa, PAGE_SIZE);
+
+		vmsa->handle = sev->handle;
+		vmsa->address = __sme_pa(svm->vmsa);
+		vmsa->len = PAGE_SIZE;
+		ret = sev_issue_cmd(kvm, SEV_CMD_LAUNCH_UPDATE_VMSA, vmsa,
+				    &argp->error);
+		if (ret)
+			goto e_free;
+
+		svm->vcpu.arch.guest_state_protected = true;
+	}
+
+e_free:
+	kfree(vmsa);
+	return ret;
+}
+
 static int sev_launch_measure(struct kvm *kvm, struct kvm_sev_cmd *argp)
 {
 	void __user *measure = (void __user *)(uintptr_t)argp->data;
@@ -957,12 +1055,18 @@ int svm_mem_enc_op(struct kvm *kvm, void __user *argp)
 	case KVM_SEV_INIT:
 		r = sev_guest_init(kvm, &sev_cmd);
 		break;
+	case KVM_SEV_ES_INIT:
+		r = sev_es_guest_init(kvm, &sev_cmd);
+		break;
 	case KVM_SEV_LAUNCH_START:
 		r = sev_launch_start(kvm, &sev_cmd);
 		break;
 	case KVM_SEV_LAUNCH_UPDATE_DATA:
 		r = sev_launch_update_data(kvm, &sev_cmd);
 		break;
+	case KVM_SEV_LAUNCH_UPDATE_VMSA:
+		r = sev_launch_update_vmsa(kvm, &sev_cmd);
+		break;
 	case KVM_SEV_LAUNCH_MEASURE:
 		r = sev_launch_measure(kvm, &sev_cmd);
 		break;
-- 
2.28.0


      parent reply	other threads:[~2020-10-02 17:07 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-02 17:02 [RFC PATCH v2 00/33] SEV-ES hypervisor support Tom Lendacky
2020-10-02 17:02 ` [RFC PATCH v2 01/33] KVM: SVM: Remove the call to sev_platform_status() during setup Tom Lendacky
2020-10-02 17:02 ` [RFC PATCH v2 02/33] KVM: SVM: Add support for SEV-ES capability in KVM Tom Lendacky
2020-10-02 17:02 ` [RFC PATCH v2 03/33] KVM: SVM: Add GHCB accessor functions for retrieving fields Tom Lendacky
2020-10-02 17:02 ` [RFC PATCH v2 04/33] KVM: SVM: Add support for the SEV-ES VMSA Tom Lendacky
2020-10-02 17:02 ` [RFC PATCH v2 05/33] KVM: x86: Mark GPRs dirty when written Tom Lendacky
2020-10-02 17:02 ` [RFC PATCH v2 06/33] KVM: SVM: Add required changes to support intercepts under SEV-ES Tom Lendacky
2020-10-02 17:02 ` [RFC PATCH v2 07/33] KVM: SVM: Prevent debugging " Tom Lendacky
2020-10-02 17:02 ` [RFC PATCH v2 08/33] KVM: SVM: Do not allow instruction emulation " Tom Lendacky
2020-10-02 17:02 ` [RFC PATCH v2 09/33] KVM: SVM: Cannot re-initialize the VMCB after shutdown with SEV-ES Tom Lendacky
2020-10-02 17:02 ` [RFC PATCH v2 10/33] KVM: SVM: Prepare for SEV-ES exit handling in the sev.c file Tom Lendacky
2020-10-02 17:02 ` [RFC PATCH v2 11/33] KVM: SVM: Add initial support for a VMGEXIT VMEXIT Tom Lendacky
2020-10-02 17:02 ` [RFC PATCH v2 12/33] KVM: SVM: Create trace events for VMGEXIT processing Tom Lendacky
2020-10-02 17:02 ` [RFC PATCH v2 13/33] KVM: SVM: Add support for SEV-ES GHCB MSR protocol function 0x002 Tom Lendacky
2020-10-02 17:02 ` [RFC PATCH v2 14/33] KVM: SVM: Add support for SEV-ES GHCB MSR protocol function 0x004 Tom Lendacky
2020-10-02 17:02 ` [RFC PATCH v2 15/33] KVM: SVM: Add support for SEV-ES GHCB MSR protocol function 0x100 Tom Lendacky
2020-10-02 17:02 ` [RFC PATCH v2 16/33] KVM: SVM: Create trace events for VMGEXIT MSR protocol processing Tom Lendacky
2020-10-02 17:02 ` [RFC PATCH v2 17/33] KVM: SVM: Support MMIO for an SEV-ES guest Tom Lendacky
2020-10-02 17:02 ` [RFC PATCH v2 18/33] KVM: SVM: Support port IO operations " Tom Lendacky
2020-10-02 17:02 ` [RFC PATCH v2 19/33] KVM: SVM: Add support for EFER write traps " Tom Lendacky
2020-10-02 17:02 ` [RFC PATCH v2 20/33] KVM: SVM: Add support for CR0 " Tom Lendacky
2020-10-02 17:02 ` [RFC PATCH v2 21/33] KVM: SVM: Add support for CR4 " Tom Lendacky
2020-10-02 17:02 ` [RFC PATCH v2 22/33] KVM: SVM: Add support for CR8 " Tom Lendacky
2020-10-02 17:02 ` [RFC PATCH v2 23/33] KVM: x86: Update __get_sregs() / __set_sregs() to support SEV-ES Tom Lendacky
2020-10-02 17:02 ` [RFC PATCH v2 24/33] KVM: SVM: Do not report support for SMM for an SEV-ES guest Tom Lendacky
2020-10-02 17:02 ` [RFC PATCH v2 25/33] KVM: SVM: Guest FPU state save/restore not needed for " Tom Lendacky
2020-10-02 17:02 ` [RFC PATCH v2 26/33] KVM: SVM: Add support for booting APs for an " Tom Lendacky
2020-10-02 17:02 ` [RFC PATCH v2 27/33] KVM: SVM: Add NMI support " Tom Lendacky
2020-10-02 17:02 ` [RFC PATCH v2 28/33] KVM: SVM: Set the encryption mask for the SVM host save area Tom Lendacky
2020-10-02 17:02 ` [RFC PATCH v2 29/33] KVM: SVM: Update ASID allocation to support SEV-ES guests Tom Lendacky
2020-10-02 17:02 ` [RFC PATCH v2 30/33] KVM: SVM: Provide support for SEV-ES vCPU creation/loading Tom Lendacky
2020-10-02 17:02 ` [RFC PATCH v2 31/33] KVM: SVM: Provide support for SEV-ES vCPU loading Tom Lendacky
2020-10-02 17:02 ` [RFC PATCH v2 32/33] KVM: SVM: Provide an updated VMRUN invocation for SEV-ES guests Tom Lendacky
2020-10-02 17:02 ` Tom Lendacky [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aa7c1443b61df6ab2d3b5f4deeaf9e9925b65469.1601658176.git.thomas.lendacky@amd.com \
    --to=thomas.lendacky@amd.com \
    --cc=bp@alien8.de \
    --cc=brijesh.singh@amd.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=sean.j.christopherson@intel.com \
    --cc=tglx@linutronix.de \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).