On Fri, 2024-03-01 at 19:00 +0000, Michael Kelley wrote: > From: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx> Sent: Wednesday, > February 21, 2024 6:10 PM > > > > Historically, the preferred Subject prefix for changes to > connection.c has > been "Drivers: hv: vmbus:", not just "hv:". Sometimes that > preference > isn't followed, but most of the time it is. Ok, I can update it. > > > 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. > > > set_memory_encrypted() or set_memory_decrypted() to fail such that > > an > > error is returned and the resulting memory is shared. Callers need > > to take > > care to handle these errors to avoid returning decrypted (shared) > > memory to > > the page allocator, which could lead to functional or security > > issues. > > > > Hyperv could free decrypted/shared pages if set_memory_encrypted() > > fails. > > It's not Hyper-V doing the freeing. Maybe say "VMBus code could > free ...." Ok.
