On Tue, Nov 21, 2023 at 01:20:08PM -0800, mhkelley58@xxxxxxxxx wrote: > From: Michael Kelley <mhklinux@xxxxxxxxxxx> > > In a CoCo VM when a page transitions from encrypted to decrypted, or vice > versa, attributes in the PTE must be updated *and* the hypervisor must > be notified of the change. Strictly speaking it is not true for TDX. Conversion to shared can be implicit: set shared bit and touch the page will do the conversion. MapGPA is optional. > Because there are two separate steps, there's > a window where the settings are inconsistent. Normally the code that > initiates the transition (via set_memory_decrypted() or > set_memory_encrypted()) ensures that the memory is not being accessed > during a transition, so the window of inconsistency is not a problem. > However, the load_unaligned_zeropad() function can read arbitrary memory > pages at arbitrary times, which could read a transitioning page during > the window. In such a case, CoCo VM specific exceptions are taken > (depending on the CoCo architecture in use). Current code in those > exception handlers recovers and does "fixup" on the result returned by > load_unaligned_zeropad(). Unfortunately, this exception handling can't > work in paravisor scenarios (TDX Paritioning and SEV-SNP in vTOM mode) > if the exceptions are routed to the paravisor. The paravisor can't > do load_unaligned_zeropad() fixup, so the exceptions would need to > be forwarded from the paravisor to the Linux guest, but there are > no architectural specs for how to do that. Hm. Can't we inject #PF (or #GP) into L2 if #VE/#VC handler in L1 sees cross-page access to shared memory while no fixup entry for the page in L1. It would give L2 chance to handle the situation in a transparent way. Maybe I miss something, I donno. -- Kiryl Shutsemau / Kirill A. Shutemov
