linux-kernel - Re: [PATCH v15 13/20] KVM: SEV: Implement gmem hook for initializing private pages

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: <e771a7ba-0445-483e-9c42-66bd5b331dce@intel.com>
Date: Tue, 21 May 2024 09:57:36 +1200
From: "Huang, Kai" <kai.huang@...el.com>
To: Sean Christopherson <seanjc@...gle.com>
CC: "isaku.yamahata@...il.com" <isaku.yamahata@...il.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>, Rick P Edgecombe
	<rick.p.edgecombe@...el.com>, "michael.roth@....com" <michael.roth@....com>,
	"pankaj.gupta@....com" <pankaj.gupta@....com>, "tglx@...utronix.de"
	<tglx@...utronix.de>, "tobin@....com" <tobin@....com>,
	"liam.merwick@...cle.com" <liam.merwick@...cle.com>, "alpergun@...gle.com"
	<alpergun@...gle.com>, Tony Luck <tony.luck@...el.com>, "jmattson@...gle.com"
	<jmattson@...gle.com>, "luto@...nel.org" <luto@...nel.org>,
	"ak@...ux.intel.com" <ak@...ux.intel.com>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>, "pgonda@...gle.com" <pgonda@...gle.com>,
	"srinivas.pandruvada@...ux.intel.com" <srinivas.pandruvada@...ux.intel.com>,
	"slp@...hat.com" <slp@...hat.com>, "rientjes@...gle.com"
	<rientjes@...gle.com>, "peterz@...radead.org" <peterz@...radead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"dovmurik@...ux.ibm.com" <dovmurik@...ux.ibm.com>, "thomas.lendacky@....com"
	<thomas.lendacky@....com>, "x86@...nel.org" <x86@...nel.org>, "bp@...en8.de"
	<bp@...en8.de>, "vkuznets@...hat.com" <vkuznets@...hat.com>, "vbabka@...e.cz"
	<vbabka@...e.cz>, "ashish.kalra@....com" <ashish.kalra@....com>,
	"linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>,
	"nikunj.dadhania@....com" <nikunj.dadhania@....com>, Jorg Rodel
	<jroedel@...e.de>, "mingo@...hat.com" <mingo@...hat.com>,
	"sathyanarayanan.kuppuswamy@...ux.intel.com"
	<sathyanarayanan.kuppuswamy@...ux.intel.com>, "hpa@...or.com"
	<hpa@...or.com>, "kirill@...temov.name" <kirill@...temov.name>,
	"jarkko@...nel.org" <jarkko@...nel.org>, "ardb@...nel.org" <ardb@...nel.org>,
	"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>, "dave.hansen@...ux.intel.com"
	<dave.hansen@...ux.intel.com>
Subject: Re: [PATCH v15 13/20] KVM: SEV: Implement gmem hook for initializing
 private pages



On 21/05/2024 5:35 am, Sean Christopherson wrote:
> On Mon, May 20, 2024, Kai Huang wrote:
>> On Wed, 2024-05-01 at 03:52 -0500, Michael Roth wrote:
>>> This will handle the RMP table updates needed to put a page into a
>>> private state before mapping it into an SEV-SNP guest.
>>>
>>>
>>
>> [...]
>>
>>> +int sev_gmem_prepare(struct kvm *kvm, kvm_pfn_t pfn, gfn_t gfn, int max_order)
> 
> ...
> 
>> +Rick, Isaku,
>>
>> I am wondering whether this can be done in the KVM page fault handler?
> 
> No, because the state of a pfn in the RMP is tied to the guest_memfd inode, not
> to the file descriptor, i.e. not to an individual VM.  

It's strange that as state of a PFN of SNP doesn't bind to individual 
VM, at least for the private pages.  The command rpm_make_private() 
indeed reflects the mapping between PFN <-> <GFN, SSID>.

	rc = rmp_make_private(pfn_aligned, gfn_to_gpa(gfn_aligned),
			level, sev->asid, false);

> And the NPT page tables
> are treated as ephemeral for SNP.
> 

Do you mean private mappings for SNP guest can be zapped from the VM 
(the private pages are still there unchanged) and re-mapped later w/o 
needing to have guest's explicit acceptance?

If so, I think "we can zap" doesn't mean "we need to zap"?  Because the 
privates are now pinned anyway.  If we truly want to zap private 
mappings for SNP, IIUC it can be done by distinguishing whether a VM 
needs to use a separate private table, which is TDX-only.

I'll look into the SNP spec to understand more.