| 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
| ||
|
Message-ID: <CAAH4kHb03Una2kcvyC3W=1ZfANBWF_7a7zsSmWhr_r9g3rCDZw@mail.gmail.com>
Date: Fri, 16 Aug 2024 14:50:59 -0700
From: Dionna Amalie Glaze <dionnaglaze@...gle.com>
To: Michael Roth <michael.roth@....com>
Cc: seanjc@...gle.com, kvm@...r.kernel.org, linux-coco@...ts.linux.dev,
linux-mm@...ck.org, linux-crypto@...r.kernel.org, x86@...nel.org,
linux-kernel@...r.kernel.org, tglx@...utronix.de, mingo@...hat.com,
jroedel@...e.de, thomas.lendacky@....com, hpa@...or.com, ardb@...nel.org,
pbonzini@...hat.com, vkuznets@...hat.com, jmattson@...gle.com,
luto@...nel.org, dave.hansen@...ux.intel.com, slp@...hat.com,
pgonda@...gle.com, peterz@...radead.org, srinivas.pandruvada@...ux.intel.com,
rientjes@...gle.com, dovmurik@...ux.ibm.com, tobin@....com, bp@...en8.de,
vbabka@...e.cz, kirill@...temov.name, ak@...ux.intel.com, tony.luck@...el.com,
sathyanarayanan.kuppuswamy@...ux.intel.com, alpergun@...gle.com,
jarkko@...nel.org, ashish.kalra@....com, nikunj.dadhania@....com,
pankaj.gupta@....com, liam.merwick@...cle.com, papaluri@....com
Subject: Re: [PATCH] KVM: SEV: Replace KVM_EXIT_VMGEXIT with KVM_EXIT_SNP_REQ_CERTS
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -4006,21 +4006,14 @@ static int snp_complete_ext_guest_req(struct kvm_vcpu *vcpu)
> sev_ret_code fw_err = 0;
> int vmm_ret;
>
> - vmm_ret = vcpu->run->vmgexit.req_certs.ret;
> + vmm_ret = vcpu->run->snp_req_certs.ret;
> if (vmm_ret) {
> if (vmm_ret == SNP_GUEST_VMM_ERR_INVALID_LEN)
> vcpu->arch.regs[VCPU_REGS_RBX] =
> - vcpu->run->vmgexit.req_certs.data_npages;
> + vcpu->run->snp_req_certs.data_npages;
> goto out;
> }
Finally getting around to this patch. Thanks for your patience.
Whether the exit to guest for certs is first or second when getting
the attestation report, the certificates need to be
consistent. Since we don't have any locks held before exiting, and no
checks happening on the result, there's a
chance that a well-intentioned host can still provide the wrong
certificate to the guest when VMs are running and requesting
attestations during a firmware hotload.
Thread 1:
DOWNLOAD_FIRMWARE_EX please
CURRENT_TCB > REPORTED_TCB
(notify service to get a new VCEK cert)
Interrupted
Thread 2:
VM extended guest request in.
Exit to user space
Call SNP_PLATFORM_STATUS to get REPORTED_TCB.
Get certs for REPORTED_TCB for the blob. It's at /x/y/z-REPORTED_TCB.crt.
Interrupted
Thread 1:
I got my VCEK cert delivered for CURRENT_TCB! I'll put it at
/x/y/z-CURRENT_TCB.crt
Great. SNP_COMMIT.
Now both REPORTED_TCB and COMMITTED_TCB to CURRENT_TCB, because that's
the spec. Different reported_tcb here. than in thread 1.
Interrupted
Thread 2:
Get the attestation report. It will be signed by the VCEK versioned to
the newer REPORTED_TCB.
Return to VM guest
VM guest:
My report's signature doesn't verify with the VCEK cert I was given.
Yes, 1-88-COM-PLAIN?
How do we avoid this?
1. We can advise that the guest parses the certificate and the
attestation report to determine if their TCBs match expectations and
retry if they're different because of a bad luck data race.
2. We can add a new global lock that KVM holds from CCP similar to
sev_cmd_lock to sequentialize req_certs, attestation reports, and
SNP_COMMIT. KVM releases the lock before returning to the guest.
SNP_COMMIT must now hold this lock before attempting to grab the sev_cmd_lock.
I think probably 2 is better.
>
> @@ -4060,12 +4045,9 @@ static int snp_begin_ext_guest_req(struct kvm_vcpu *vcpu)
> * Grab the certificates from userspace so that can be bundled with
> * attestation/guest requests.
> */
> - vcpu->run->exit_reason = KVM_EXIT_VMGEXIT;
> - vcpu->run->vmgexit.type = KVM_USER_VMGEXIT_REQ_CERTS;
> - vcpu->run->vmgexit.req_certs.data_gpa = data_gpa;
> - vcpu->run->vmgexit.req_certs.data_npages = data_npages;
> - vcpu->run->vmgexit.req_certs.flags = 0;
> - vcpu->run->vmgexit.req_certs.status = KVM_USER_VMGEXIT_REQ_CERTS_STATUS_PENDING;
> + vcpu->run->exit_reason = KVM_EXIT_SNP_REQ_CERTS;
This should be whatever exit reason #define you go with (40), not the
(1) you defined for kvm_snp_exit.
> + vcpu->run->snp_req_certs.data_gpa = data_gpa;
> + vcpu->run->snp_req_certs.data_npages = data_npages;
> vcpu->arch.complete_userspace_io = snp_complete_ext_guest_req;
>
> return 0; /* forward request to userspace */
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 106367d87189..8ebfc91dc967 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -135,22 +135,17 @@ struct kvm_xen_exit {
> } u;
> };
>
> -struct kvm_user_vmgexit {
> -#define KVM_USER_VMGEXIT_REQ_CERTS 1
> - __u32 type; /* KVM_USER_VMGEXIT_* type */
> +struct kvm_exit_snp {
> +#define KVM_EXIT_SNP_REQ_CERTS 1
> + __u32 type; /* KVM_EXIT_SNP_* type */
I think this whole struct should be removed since we're only doing the
one exit reason. This is unused.
You also double-#define the return value preprocessor directives.
> };
> @@ -198,7 +193,7 @@ struct kvm_user_vmgexit {
> #define KVM_EXIT_NOTIFY 37
> #define KVM_EXIT_LOONGARCH_IOCSR 38
> #define KVM_EXIT_MEMORY_FAULT 39
> -#define KVM_EXIT_VMGEXIT 40
> +#define KVM_EXIT_SNP_REQUEST_CERTS 40
Probably we should just make this KVM_EXT_SNP_REQ_CERTS so the rest of
the code works.
>
> /* For KVM_EXIT_INTERNAL_ERROR */
> /* Emulate instruction failed. */
> @@ -454,8 +449,16 @@ struct kvm_run {
> __u64 gpa;
> __u64 size;
> } memory_fault;
> - /* KVM_EXIT_VMGEXIT */
> - struct kvm_user_vmgexit vmgexit;
> + /* KVM_EXIT_SNP_REQ_CERTS */
> + struct {
> + __u64 data_gpa;
> + __u64 data_npages;
> +#define KVM_EXIT_SNP_REQ_CERTS_ERROR_INVALID_LEN 1
> +#define KVM_EXIT_SNP_REQ_CERTS_ERROR_BUSY 2
> +#define KVM_EXIT_SNP_REQ_CERTS_ERROR_GENERIC (1 << 31)
> + __u32 ret;
> + } snp_req_certs;
> +
> /* Fix the size of the union. */
> char padding[256];
> };
> --
> 2.25.1
>
>
--
-Dionna Glaze, PhD, CISSP, CCSP (she/her)
Powered by blists - more mailing lists