linux-kernel - Re: [PATCH v12 11/29] KVM: SEV: Add KVM_SEV_SNP_LAUNCH

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]

Message-ID: <20240403153738.GC2444378@ls.amr.corp.intel.com>
Date: Wed, 3 Apr 2024 08:37:38 -0700
From: Isaku Yamahata <isaku.yamahata@...el.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: Isaku Yamahata <isaku.yamahata@...el.com>,
	Michael Roth <michael.roth@....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, 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, 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,
	Brijesh Singh <brijesh.singh@....com>,
	Xu Yilun <yilun.xu@...ux.intel.com>,
	Binbin Wu <binbin.wu@...ux.intel.com>,
	Xiaoyao Li <xiaoyao.li@...el.com>, isaku.yamahata@...ux.intel.com
Subject: Re: [PATCH v12 11/29] KVM: SEV: Add KVM_SEV_SNP_LAUNCH_UPDATE command

On Wed, Apr 03, 2024 at 02:51:59PM +0200,
Paolo Bonzini <pbonzini@...hat.com> wrote:

> On Wed, Apr 3, 2024 at 12:58 AM Isaku Yamahata <isaku.yamahata@...el.com> wrote:
> > I think TDX can use it with slight change. Pass vcpu instead of KVM, page pin
> > down and mmu_lock.  TDX requires non-leaf Secure page tables to be populated
> > before adding a leaf.  Maybe with the assumption that vcpu doesn't run, GFN->PFN
> > relation is stable so that mmu_lock isn't needed? What about punch hole?
> >
> > The flow would be something like as follows.
> >
> > - lock slots_lock
> >
> > - kvm_gmem_populate(vcpu)
> >   - pin down source page instead of do_memcopy.
> 
> Both pinning the source page and the memcpy can be done in the
> callback.  I think the right thing to do is:
> 
> 1) eliminate do_memcpy, letting AMD code taking care of
>    copy_from_user.
> 
> 2) pass to the callback only gfn/pfn/src, where src is computed as
> 
>     args->src ? args->src + i * PAGE_SIZE : NULL
> 
> If another architecture/vendor needs do_memcpy, they can add
> something like kvm_gmem_populate_copy.
> 
> >   - get pfn with __kvm_gmem_get_pfn()
> >   - read lock mmu_lock
> >   - in the post_populate callback
> >     - lookup tdp mmu page table to check if the table is populated.
> >       lookup only version of kvm_tdp_mmu_map().
> >       We need vcpu instead of kvm.
> 
> Passing vcpu can be done using the opaque callback argument to
> kvm_gmem_populate.
> 
> Likewise, the mmu_lock can be taken by the TDX post_populate
> callback.

Yes, it should work.  Let me give it a try.
-- 
Isaku Yamahata <isaku.yamahata@...el.com>