Ackerley Tng <[email protected]> writes: > > [...snip...] > > > TLDR: > > + PRESERVE == guarantee that the process of setting memory attributes > doesn't change memory contents. > + implementation == do nothing in most cases, except -EOPNOTSUPP for > to-shared on TDX, since unmapping is a required part of setting > memory attributes to private, and a TDX side effect of unmapping > is zeroing memory,
-EOPNOTSUPP will only be for TDX, not SNP. > + ZERO == guarantee that the process of setting memory attributes zeroes > memory contents. > + implementation == memset(zero) in most cases. For TDX, a future > optimization exists, where memset() can be skipped for pages that > were mapped in Secure EPTs before conversion > + UNSPECIFIED == no guarantees > + implementation == guest_memfd does nothing explicitly about memory > contents. The implementation is pretty much the same as PRESERVE > except guest_memfd won't take into account vendor-specific side > effects of the process of conversion. Except for the test vehicle > KVM_X86_SW_PROTECTED_VMS, where memory is scrambled. > Found another use case internally for pre-finalize, SNP, to-shared, PRESERVE, which works with the above smaller scope. During SNP_LAUNCH_UPDATE, when inserting a CPUID page, the firmware will check that the CPUID values would not lead to an insecure guest state. SNP_LAUNCH_UPDATE will fail with an error and the page remains shared in the RMP table. Here's the proposed flow in the userspace VMM: 1. Load CPUID in shared guest_memfd memory 2. SET_MEMORY_ATTRIBUTES(PRIVATE, PRESERVE) 3. SNP_LAUNCH_UPDATE => get error since CPUID was insecure 4. SET_MEMORY_ATTRIBUTES(SHARED, PRESERVE) 5. Read shared guest_memfd memory, error if VMM disagrees 6. SET_MEMORY_ATTRIBUTES(PRIVATE, PRESERVE) 7. SNP_LAUNCH_UPDATE => successful, since CPUID is now corrected Does that seem ok? >>> >>> [...snip...] >>>
