From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@xxxxxxxxxxxxxxx> Sent: Monday, January 8, 2024 10:37 AM > > On 1/5/2024 10:30 AM, mhkelley58@xxxxxxxxx wrote: > > From: Michael Kelley <mhklinux@xxxxxxxxxxx> > > > > In a CoCo VM, when transitioning memory from encrypted to decrypted, or > > vice versa, the caller of set_memory_encrypted() or set_memory_decrypted() > > is responsible for ensuring the memory isn't in use and isn't referenced > > while the transition is in progress. The transition has multiple steps, > > and the memory is in an inconsistent state until all steps are complete. > > A reference while the state is inconsistent could result in an exception > > that can't be cleanly fixed up. > > > > However, the kernel load_unaligned_zeropad() mechanism could cause a stray > > reference that can't be prevented by the caller of set_memory_encrypted() > > or set_memory_decrypted(), so there's specific code to handle this case. > > But a CoCo VM running on Hyper-V may be configured to run with a paravisor, > > with the #VC or #VE exception routed to the paravisor. There's no > > architectural way to forward the exceptions back to the guest kernel, and > > in such a case, the load_unaligned_zeropad() specific code doesn't work. > > > > To avoid this problem, mark pages as "not present" while a transition > > is in progress. If load_unaligned_zeropad() causes a stray reference, a > > normal page fault is generated instead of #VC or #VE, and the > > page-fault-based fixup handlers for load_unaligned_zeropad() resolve the > > reference. When the encrypted/decrypted transition is complete, mark the > > pages as "present" again. > > Change looks good to me. But I am wondering why are adding it part of > prepare and finish callbacks instead of directly in set_memory_encrypted() function. > The prepare/finish callbacks are different for TDX, SEV-SNP, and Hyper-V CoCo guests running with a paravisor -- so there are three sets of callbacks. As described in the cover letter, I've given up on using this scheme for the TDX and SEV-SNP cases, because of the difficulty with the SEV-SNP callbacks needing a valid virtual address (whereas TDX and Hyper-V paravisor need only a physical address). So it seems like the callbacks specific to the Hyper-V paravisor are the natural place for the code. That leaves the TDX and SEV-SNP code paths unchanged, which was my intent. Or maybe I'm not understanding your comment? If that's the case, please elaborate. Michael > Reviewed-by: Kuppuswamy Sathyanarayanan > <sathyanarayanan.kuppuswamy@xxxxxxxxxxxxxxx> >
