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, 15 Aug 2022 23:04:49 +0000
From:   "Kalra, Ashish" <Ashish.Kalra@....com>
To:     Sabin Rapan <sabrapan@...zon.com>
CC:     "ak@...ux.intel.com" <ak@...ux.intel.com>,
        "alpergun@...gle.com" <alpergun@...gle.com>,
        "ardb@...nel.org" <ardb@...nel.org>, "bp@...en8.de" <bp@...en8.de>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "dgilbert@...hat.com" <dgilbert@...hat.com>,
        "dovmurik@...ux.ibm.com" <dovmurik@...ux.ibm.com>,
        "hpa@...or.com" <hpa@...or.com>,
        "jarkko@...nel.org" <jarkko@...nel.org>,
        "jmattson@...gle.com" <jmattson@...gle.com>,
        "jroedel@...e.de" <jroedel@...e.de>,
        "kirill@...temov.name" <kirill@...temov.name>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "luto@...nel.org" <luto@...nel.org>,
        "marcorr@...gle.com" <marcorr@...gle.com>,
        "Roth, Michael" <Michael.Roth@....com>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "pgonda@...gle.com" <pgonda@...gle.com>,
        "rientjes@...gle.com" <rientjes@...gle.com>,
        "sathyanarayanan.kuppuswamy@...ux.intel.com" 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        "seanjc@...gle.com" <seanjc@...gle.com>,
        "slp@...hat.com" <slp@...hat.com>,
        "srinivas.pandruvada@...ux.intel.com" 
        <srinivas.pandruvada@...ux.intel.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "Lendacky, Thomas" <Thomas.Lendacky@....com>,
        "tobin@....com" <tobin@....com>,
        "tony.luck@...el.com" <tony.luck@...el.com>,
        "vbabka@...e.cz" <vbabka@...e.cz>,
        "vkuznets@...hat.com" <vkuznets@...hat.com>,
        "x86@...nel.org" <x86@...nel.org>
Subject: RE: [PATCH Part2 v6 26/49] KVM: SVM: Add KVM_SEV_SNP_LAUNCH_UPDATE
 command 

[AMD Official Use Only - General]

Hello Sabin,

>> +static bool is_hva_registered(struct kvm *kvm, hva_t hva, size_t len) 
>> +{
>> +	struct kvm_sev_info *sev = &to_kvm_svm(kvm)->sev_info;
>> +	struct list_head *head = &sev->regions_list;
>> +	struct enc_region *i;
>> +
>> +	lockdep_assert_held(&kvm->lock);
>> +
>> +	list_for_each_entry(i, head, list) {
>> +		u64 start = i->uaddr;
>> +		u64 end = start + i->size;
>> +
>> +		if (start <= hva && end >= (hva + len))
>> +			return true;
>> +	}
>> +
>> +	return false;
>> +}

>Since KVM_MEMORY_ENCRYPT_REG_REGION should be called for every memory region the user gives to kvm, is the regions_list any different from kvm's memslots?

Actually, the KVM_MEMORY_ENCRYPT_REG_REGION is being called and the regions_list is only being setup for the guest RAM blocks.

>> +
>> +static int snp_launch_update(struct kvm *kvm, struct kvm_sev_cmd 
>> +*argp) {
>> +	struct kvm_sev_info *sev = &to_kvm_svm(kvm)->sev_info;
>> +	struct sev_data_snp_launch_update data = {0};
>> +	struct kvm_sev_snp_launch_update params;
>> +	unsigned long npages, pfn, n = 0;
>> +	int *error = &argp->error;
>> +	struct page **inpages;
>> +	int ret, i, level;
>> +	u64 gfn;
>> +
>> +	if (!sev_snp_guest(kvm))
>> +		return -ENOTTY;
>> +
>> +	if (!sev->snp_context)
>> +		return -EINVAL;
>> +
>> +	if (copy_from_user(&params, (void __user *)(uintptr_t)argp->data, sizeof(params)))
>> +		return -EFAULT;
>> +
>> +	/* Verify that the specified address range is registered. */
>> +	if (!is_hva_registered(kvm, params.uaddr, params.len))
>> +		return -EINVAL;
>> +
>> +	/*
>> +	 * The userspace memory is already locked so technically we don't
>> +	 * need to lock it again. Later part of the function needs to know
>> +	 * pfn so call the sev_pin_memory() so that we can get the list of
>> +	 * pages to iterate through.
>> +	 */
>> +	inpages = sev_pin_memory(kvm, params.uaddr, params.len, &npages, 1);
>> +	if (!inpages)
>> +		return -ENOMEM;

>sev_pin_memory will call pin_user_pages() which fails for PFNMAP vmas that you would get if you use memory allocated from an IO driver.
>Using gfn_to_pfn instead will make this work with vmas backed by pages or raw pfn mappings.

All the guest memory is being allocated via the userspace VMM, so how and where will we get memory allocated from an IO driver ?

Thanks,
Ashish

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ