linux-kernel - Re: [PATCH v8 8.2/9] x86/virt/tdx: Reduce TDMR's reserved areas by using CMRs to find memory holes

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: <6757aba1e072f_3e0fe294a5@dwillia2-mobl3.amr.corp.intel.com.notmuch>
Date: Mon, 9 Dec 2024 18:46:57 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: "Huang, Kai" <kai.huang@...el.com>, "Hansen, Dave"
	<dave.hansen@...el.com>, "seanjc@...gle.com" <seanjc@...gle.com>,
	"bp@...en8.de" <bp@...en8.de>, "peterz@...radead.org" <peterz@...radead.org>,
	"hpa@...or.com" <hpa@...or.com>, "mingo@...hat.com" <mingo@...hat.com>,
	"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>, "Williams, Dan J" <dan.j.williams@...el.com>
CC: "nik.borisov@...e.com" <nik.borisov@...e.com>, "Hunter, Adrian"
	<adrian.hunter@...el.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "Edgecombe, Rick P"
	<rick.p.edgecombe@...el.com>, "x86@...nel.org" <x86@...nel.org>, "Yamahata,
 Isaku" <isaku.yamahata@...el.com>
Subject: Re: [PATCH v8 8.2/9] x86/virt/tdx: Reduce TDMR's reserved areas by
 using CMRs to find memory holes

Huang, Kai wrote:
[..]
> > So in the end, I buy that the CMR's have something to offer here. But I
> > think that "why" I mentioned above casts doubt on whether
> > for_each_mem_pfn_range() is the right primitive on which to build the
> > TDX memblocks in the first place.
> 
> We can change to just use CMRs as TDX memory blocks, i.e., always cover all CMRs
> in TDMRs, but this will have much wider impact.
> 
> The main concern is the PAMT allocation: PAMT is allocated from page allocator,
> but the CMRs -- the RAM as defined by the platform and the TDX module - - can
> cover more, and sometimes much more, regions than the regions end up to the page
> allocator.
> 
> E.g., today we can use 'memmap=' to reserve part of memory for other purpose. 
> And in the future CMRs may cover CXL memory regions which could be much larger
> IIUC.

Please do not point to memmap= as a reason to complicate the TDX
initialization. memmap= is a debug / expert feature where the user gets
to keep all the pieces if they get it wrong.

Please do not point to theoretical CXL futures as a reason not to do the
right thing in TDX initialization. The CXL TEE Security Protocol makes
CXL memory indistinguishable from DDR. It is layering violation for TDX
module initialization to add complexity and policy assumptions as if it
knows better than the published CMRs what memory resources are available
in the platform.

Please drop my reviewed-by on this patch until we have a solution and a
simple story for the recently discovered problems that CMR enumeration
solves. This includes reserve-area population and disambiguating
reserve-area enumeration from late-to-online memory resources.