linux-kernel - Re: [PATCH v1 11/26] x86/sev: Invalidate pages from the direct map when adding them to the RMP table

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: <20240116182158.GHZabJRqUMAEidcee1@fat_crate.local>
Date: Tue, 16 Jan 2024 19:22:10 +0100
From: Borislav Petkov <bp@...en8.de>
To: Michael Roth <michael.roth@....com>
Cc: Dave Hansen <dave.hansen@...el.com>,
	Tom Lendacky <thomas.lendacky@....com>, x86@...nel.org,
	kvm@...r.kernel.org, linux-coco@...ts.linux.dev, linux-mm@...ck.org,
	linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
	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,
	tobin@....com, 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>, rppt@...nel.org
Subject: Re: [PATCH v1 11/26] x86/sev: Invalidate pages from the direct map
 when adding them to the RMP table

On Tue, Jan 16, 2024 at 10:19:09AM -0600, Michael Roth wrote:
> So at the very least, if we went down this path, we would be worth
> investigating the following areas in addition to general perf testing:
> 
>   1) Only splitting directmap regions corresponding to kernel-allocatable
>      *data* (hopefully that's even feasible...)
>   2) Potentially deferring the split until an SNP guest is actually
>      run, so there isn't any impact just from having SNP enabled (though
>      you still take a hit from RMP checks in that case so maybe it's not
>      worthwhile, but that itself has been noted as a concern for users
>      so it would be nice to not make things even worse).

So the gist of this whole explanation why we end up doing what we end up
doing eventually should be in the commit message so that it is clear
*why* we did it. 

> After further discussion I think we'd concluded it wasn't necessary. Maybe
> that's worth revisiting though. If it is necessary, then that would be
> another reason to just pre-split the directmap because the above-mentioned
> lazy acceptance workload/bottleneck would likely get substantially worse.

The reason for that should also be in the commit message.

And to answer:

https://lore.kernel.org/linux-mm/20221219150026.bltiyk72pmdc2ic3@amd.com/

yes, you should add a @npages variant.

See if you could use/extend this, for example:

https://lore.kernel.org/r/20240116022008.1023398-3-mhklinux@outlook.com

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette