From: Edgecombe, Rick P <rick.p.edgecombe@intel.com> Sent: Friday, March 1, 2024 11:13 AM

quoted

quoted

On TDX it is possible for the untrusted host to cause

I'd argue that this is for CoCo VMs in general, not just TDX.  I don't know
all the failure modes for SEV-SNP, but the code paths you are changing
are run in both TDX and SEV-SNP CoCo VMs.

On SEV-SNP the host can cause the call to fail too was my
understanding. But in Linux, that side panics and never gets to the
point of being able to free the shared memory. So it's not TDX
architecture specific, it's just how Linux handles it on the different
sids. For TDX the suggestion was to avoid panicing because it is
possible to handle in SW, as Linux usually tries it's best to do.

The Hyper-V case can actually be a third path when a paravisor
is being used.  In that case, for both TDX and SEV-SNP, the
hypervisor callbacks in __set_memory_enc_pgtable() go
to Hyper-V specific functions that talk to the paravisor. Those
callbacks never panic. After a failure, either at the paravisor
level or in the paravisor talking to the hypervisor/VMM, the
decrypted/encrypted state of the memory isn't known.  So
leaking the memory is still the right thing to do, and your
patch set is good. But in the Hyper-V with paravisor case,
the leaking is applicable more broadly than just TDX.

The text in the commit message isn't something that I'll
go to the mat over.  But I wanted to offer the slightly broader
perspective. 

Michael