[AMD Official Use Only - AMD Internal Distribution Only] > -----Original Message----- > From: Sean Christopherson <sea...@google.com> > Sent: Friday, November 1, 2024 10:18 AM > To: Derek Manwaring <dere...@amazon.com> > Cc: roy...@amazon.co.uk; ackerley...@google.com; > agord...@linux.ibm.com; a...@eecs.berkeley.edu; > borntrae...@linux.ibm.com; b...@alien8.de; catalin.mari...@arm.com; > chenhua...@kernel.org; cor...@lwn.net; dave.han...@linux.intel.com; > da...@redhat.com; gerald.schae...@linux.ibm.com; g...@linux.ibm.com; > g...@amazon.com; h...@linux.ibm.com; h...@zytor.com; > jgow...@amazon.com; jthough...@google.com; kalya...@amazon.com; > ker...@xen0n.name; k...@vger.kernel.org; linux-arm- > ker...@lists.infradead.org; linux-...@vger.kernel.org; linux- > ker...@vger.kernel.org; linux-kselft...@vger.kernel.org; linux- > m...@kvack.org; linux-ri...@lists.infradead.org; linux-s...@vger.kernel.org; > linux-trace-kernel@vger.kernel.org; loonga...@lists.linux.dev; > l...@kernel.org; mathieu.desnoy...@efficios.com; mhira...@kernel.org; > mi...@redhat.com; pal...@dabbelt.com; paul.walms...@sifive.com; > pbonz...@redhat.com; pet...@infradead.org; quic_eber...@quicinc.com; > rost...@goodmis.org; r...@kernel.org; sh...@kernel.org; > sv...@linux.ibm.com; ta...@google.com; t...@linutronix.de; > vannapu...@google.com; w...@kernel.org; x...@kernel.org; > xmarc...@amazon.com; Kaplan, David <david.kap...@amd.com> > Subject: Re: [RFC PATCH v3 0/6] Direct Map Removal for guest_memfd > > Caution: This message originated from an External Source. Use proper > caution when opening attachments, clicking links, or responding. > > > +David Kaplan > > On Thu, Oct 31, 2024, Derek Manwaring wrote: > > On 2024-10-31 at 10:42+0000 Patrick Roy wrote: > > > On Thu, 2024-10-31 at 09:50 +0000, David Hildenbrand wrote: > > > > On 30.10.24 14:49, Patrick Roy wrote: > > > >> Most significantly, I've reduced the patch series to focus only > > > >> on direct map removal for guest_memfd for now, leaving the whole > > > >> "how to do non-CoCo VMs in guest_memfd" for later. If this > > > >> separation is acceptable, then I think I can drop the RFC tag in > > > >> the next revision (I've mainly kept it here because I'm not > > > >> entirely sure what to do with patches 3 and 4). > > > > > > > > Hi, > > > > > > > > keeping upcoming "shared and private memory in guest_memfd" in > > > > mind, I assume the focus would be to only remove the direct map for > private memory? > > > > > > > > So in the current upstream state, you would only be removing the > > > > direct map for private memory, currently translating to > "encrypted"/"protected" > > > > memory that is inaccessible either way already. > > > > > > > > Correct? > > > > > > Yea, with the upcomming "shared and private" stuff, I would expect > > > the the shared<->private conversions would call the routines from > > > patch 3 to restore direct map entries on private->shared, and zap > > > them on > > > shared->private. > > > > > > But as you said, the current upstream state has no notion of "shared" > > > memory in guest_memfd, so everything is private and thus everything > > > is direct map removed (although it is indeed already inaccessible > > > anyway for TDX and friends. That's what makes this patch series a > > > bit awkward :( ) > > > > TDX and SEV encryption happens between the core and main memory, so > > cached guest data we're most concerned about for transient execution > > attacks isn't necessarily inaccessible. > > > > I'd be interested what Intel, AMD, and other folks think on this, but > > I think direct map removal is worthwhile for CoCo cases as well. > > Removal of the direct map entries for guest private PFNs likely won't affect > the ability of an attacker to glean information from the unencrypted data > that's in the CPU caches, at least not on x86. Both TDX and SEV steal > physical > address > bit(s) for tagging encrypted memory, and unless things have changed on > recent AMD microarchitectures (I'm 99.9% certain Intel CPUs haven't > changed), those stolen address bits are propagated into the caches. I.e. the > encrypted and unencrypted forms of a given PFN are actually two different > physical addresses under the hood. > > I don't actually know how SEV uses the stolen PA bits though. I don't see > how it simply be the ASID, because IIUC, AMD CPUs allow for more unique > SEV-capable ASIDs than uniquely addressable PAs by the number of stolen > bits. But I would be very surprised if the tag for the cache isn't > guaranteed to > be unique per encryption key. > > David?
How the stolen PA bits are used is a microarchitectural implementation detail. It is true that the tag will be unique per encryption key. Beyond that, I'm not sure what other details are relevant to SW. --David Kaplan
