[AMD Official Use Only - AMD Internal Distribution Only]

-----Original Message-----
From: Sean Christopherson <seanjc@google.com>
Sent: Friday, November 1, 2024 10:18 AM
To: Derek Manwaring <redacted>
Cc: roypat@amazon.co.uk; ackerleytng@google.com;
agordeev@linux.ibm.com; aou@eecs.berkeley.edu;
borntraeger@linux.ibm.com; bp@alien8.de; catalin.marinas@arm.com;
chenhuacai@kernel.org; corbet@lwn.net; dave.hansen@linux.intel.com;
david@redhat.com; gerald.schaefer@linux.ibm.com; gor@linux.ibm.com;
graf@amazon.com; hca@linux.ibm.com; hpa@zytor.com;
jgowans@amazon.com; jthoughton@google.com; kalyazin@amazon.com;
kernel@xen0n.name; kvm@vger.kernel.org; linux-arm-
kernel@lists.infradead.org; linux-doc@vger.kernel.org; linux-
kernel@vger.kernel.org; linux-kselftest@vger.kernel.org; linux-
mm@kvack.org; linux-riscv@lists.infradead.org; linux-s390@vger.kernel.org;
linux-trace-kernel@vger.kernel.org; loongarch@lists.linux.dev;
luto@kernel.org; mathieu.desnoyers@efficios.com; mhiramat@kernel.org;
mingo@redhat.com; palmer@dabbelt.com; paul.walmsley@sifive.com;
pbonzini@redhat.com; peterz@infradead.org; quic_eberman@quicinc.com;
rostedt@goodmis.org; rppt@kernel.org; shuah@kernel.org;
svens@linux.ibm.com; tabba@google.com; tglx@linutronix.de;
vannapurve@google.com; will@kernel.org; x86@kernel.org;
xmarcalx@amazon.com; Kaplan, David [off-list ref]
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:

quoted

On 2024-10-31 at 10:42+0000 Patrick Roy wrote:

quoted

On Thu, 2024-10-31 at 09:50 +0000, David Hildenbrand wrote:

quoted

On 30.10.24 14:49, Patrick Roy wrote:

quoted

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?

quoted

quoted

quoted

So in the current upstream state, you would only be removing the
direct map for private memory, currently translating to

"encrypted"/"protected"

quoted

quoted

quoted

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