| 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
| ||
|
Date: Fri, 21 Oct 2022 16:30:42 -0500
From: Tom Lendacky <thomas.lendacky@....com>
To: "Kalra, Ashish" <ashish.kalra@....com>, x86@...nel.org,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
linux-coco@...ts.linux.dev, linux-mm@...ck.org,
linux-crypto@...r.kernel.org
Cc: tglx@...utronix.de, mingo@...hat.com, jroedel@...e.de,
hpa@...or.com, ardb@...nel.org, pbonzini@...hat.com,
seanjc@...gle.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,
michael.roth@....com, vbabka@...e.cz, kirill@...temov.name,
ak@...ux.intel.com, tony.luck@...el.com, marcorr@...gle.com,
sathyanarayanan.kuppuswamy@...ux.intel.com, alpergun@...gle.com,
dgilbert@...hat.com, jarkko@...nel.org
Subject: Re: [PATCH Part2 v6 42/49] KVM: SVM: Provide support for
SNP_GUEST_REQUEST NAE event
On 10/21/22 16:12, Kalra, Ashish wrote:
> Hello Tom,
>
> On 10/21/2022 2:06 PM, Tom Lendacky wrote:
>> On 6/20/22 18:13, Ashish Kalra wrote:
>>> From: Brijesh Singh <brijesh.singh@....com>
>>>
>>> Version 2 of GHCB specification added the support for two SNP Guest
>>> Request Message NAE events. The events allows for an SEV-SNP guest to
>>> make request to the SEV-SNP firmware through hypervisor using the
>>> SNP_GUEST_REQUEST API define in the SEV-SNP firmware specification.
>>>
>>> The SNP_EXT_GUEST_REQUEST is similar to SNP_GUEST_REQUEST with the
>>> difference of an additional certificate blob that can be passed through
>>> the SNP_SET_CONFIG ioctl defined in the CCP driver. The CCP driver
>>> provides snp_guest_ext_guest_request() that is used by the KVM to get
>>> both the report and certificate data at once.
>>>
>>> Signed-off-by: Brijesh Singh <brijesh.singh@....com>
>>> ---
>>> arch/x86/kvm/svm/sev.c | 196 +++++++++++++++++++++++++++++++++++++++--
>>> arch/x86/kvm/svm/svm.h | 2 +
>>> 2 files changed, 192 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
>>> index 7fc0fad87054..089af21a4efe 100644
>>> --- a/arch/x86/kvm/svm/sev.c
>>> +++ b/arch/x86/kvm/svm/sev.c
>>
>>> +static void snp_handle_ext_guest_request(struct vcpu_svm *svm, gpa_t
>>> req_gpa, gpa_t resp_gpa)
>>> +{
>>> + struct sev_data_snp_guest_request req = {0};
>>> + struct kvm_vcpu *vcpu = &svm->vcpu;
>>> + struct kvm *kvm = vcpu->kvm;
>>> + unsigned long data_npages;
>>> + struct kvm_sev_info *sev;
>>> + unsigned long rc, err;
>>> + u64 data_gpa;
>>> +
>>> + if (!sev_snp_guest(vcpu->kvm)) {
>>> + rc = SEV_RET_INVALID_GUEST;
>>> + goto e_fail;
>>> + }
>>> +
>>> + sev = &to_kvm_svm(kvm)->sev_info;
>>> +
>>> + data_gpa = vcpu->arch.regs[VCPU_REGS_RAX];
>>> + data_npages = vcpu->arch.regs[VCPU_REGS_RBX];
>>> +
>>> + if (!IS_ALIGNED(data_gpa, PAGE_SIZE)) {
>>> + rc = SEV_RET_INVALID_ADDRESS;
>>> + goto e_fail;
>>> + }
>>> +
>>> + /* Verify that requested blob will fit in certificate buffer */
>>> + if ((data_npages << PAGE_SHIFT) > SEV_FW_BLOB_MAX_SIZE) {
>>
>> Not sure this is a valid check... Isn't it OK if the guest has supplied
>> more room than is required? If the guest supplies 8 pages and the
>> hypervisor only needs to copy 1 page of data (or the
>> SEV_FW_BLOB_MAX_SIZE number of pages) that shouldn't be an error. I
>> think this check can go, right?
>>
>
> Agreed.
>
> The check should probably be
> if ((data_npages << PAGE_SHIFT) < SEV_FW_BLOB_MAX_SIZE)
No, the check should just be removed. If the number of pages required to
hold the cert data is only 1, then a data_npages value of 1 is just fine
(see below).
>
> and that check already exists in:
>
> snp_guest_ext_guest_request(...)
> {
> ...
> ...
> /*
> * Check if there is enough space to copy the certificate chain.
> Otherwise
> * return ERROR code defined in the GHCB specification.
> */
> expected_npages = sev->snp_certs_len >> PAGE_SHIFT;
> if (*npages < expected_npages) {
If expected_npages is 1, then an *npages value of 1 is OK. But if you put
the check in above that you want, you would never get here with an *npages
value of 1.
Thanks,
Tom
> *npages = expected_npages;
> *fw_err = SNP_GUEST_REQ_INVALID_LEN;
> return -EINVAL;
> }
> ...
>
> Thanks,
> Ashish
>
>> Thanks,
>> Tom
>>
>>> + rc = SEV_RET_INVALID_PARAM;
>>> + goto e_fail;
>>> + }
>>> +
>>> + mutex_lock(&sev->guest_req_lock);
>>> +
>>> + rc = snp_setup_guest_buf(svm, &req, req_gpa, resp_gpa);
>>> + if (rc)
>>> + goto unlock;
>>> +
>>> + rc = snp_guest_ext_guest_request(&req, (unsigned
>>> long)sev->snp_certs_data,
>>> + &data_npages, &err);
>>> + if (rc) {
>>> + /*
>>> + * If buffer length is small then return the expected
>>> + * length in rbx.
>>> + */
>>> + if (err == SNP_GUEST_REQ_INVALID_LEN)
>>> + vcpu->arch.regs[VCPU_REGS_RBX] = data_npages;
>>> +
>>> + /* pass the firmware error code */
>>> + rc = err;
>>> + goto cleanup;
>>> + }
>>> +
>>> + /* Copy the certificate blob in the guest memory */
>>> + if (data_npages &&
>>> + kvm_write_guest(kvm, data_gpa, sev->snp_certs_data,
>>> data_npages << PAGE_SHIFT))
>>> + rc = SEV_RET_INVALID_ADDRESS;
>>> +
>>> +cleanup:
>>> + snp_cleanup_guest_buf(&req, &rc);
>>> +
>>> +unlock:
>>> + mutex_unlock(&sev->guest_req_lock);
>>> +
>>> +e_fail:
>>> + svm_set_ghcb_sw_exit_info_2(vcpu, rc);
>>> +}
>>> +
Powered by blists - more mailing lists