Hi Ackerley, Before getting into the UAPI semantics, thank you for all the heavy lifting you've done here. Figuring out how to make it all work across the different platforms is not easy :)
<snip> > The policy definitions below provide more details: > > ``KVM_SET_MEMORY_ATTRIBUTES2_CONTENT_POLICY_ZERO`` (default) > > On a private to shared conversion, the host will read zeros from the > converted memory on the next fault after successful return of the > KVM_SET_MEMORY_ATTRIBUTES2 ioctl. > > This is not supported (-EOPNOTSUPP) for a shared to private > conversion. While some CoCo implementations do zero memory contents > such that the guest reads zeros after conversion, the guest is not > expected to trust host-provided zeroing, hence as a UAPI policy, KVM > does not make any such guarantees. The rationale for not supporting this in the UAPI isn't quite right and I think that the prohibition should be removed. It's true that the guest is not expected to trust host-provided zeroing. However, if the VMM invokes this ioctl with the ZERO policy, the zeroing is performed by the hypervisor, not by the (untrusted) host. Although pKVM handles fresh, zeroed memory provisioning via donation rather than attribute conversion, stating that the UAPI cannot make guarantees due to trust boundaries is incorrect. The hypervisor is precisely the entity the guest trusts to enforce this. The UAPI should define the semantics for a shared-to-private ZERO conversion, even if current architectures return -EOPNOTSUPP because they handle fresh memory provisioning via other mechanisms (like pKVM's donation path). How about something like the following: On a shared to private conversion, the hypervisor will zero the memory contents before mapping it into the guest's private address space, preventing the untrusted host from injecting arbitrary data into the guest. If an architecture handles zeroed-provisioning via mechanisms other than attribute conversion, it may return -EOPNOTSUPP. > For testing purposes, the KVM_X86_SW_PROTECTED_VM testing vehicle > will support this policy and ensure zeroing for conversions in both > directions. > > ``KVM_SET_MEMORY_ATTRIBUTES2_CONTENT_POLICY_PRESERVE`` > > On private/shared conversions in both directions, memory contents > will be preserved and readable. As a concrete example, if the host > writes ``0xbeef`` to memory and converts the memory to shared, the > guest will also read ``0xbeef``, after any necessary hardware or > software provided decryption. After a reverse shared to private > conversion, the host will also read ``0xbeef``. I think that this example is backwards. If the host writes to memory, that memory is already shared, isn't it? Converting it to shared is redundant. More importantly, if memory undergoes a shared-to-private conversion, the host must lose access entirely. Maybe a clearer example would reflect actual payload injection and bounce buffer sharing: - Shared-to-Private (Payload Injection): The host writes a payload (e.g., 0xbeef) to shared memory and converts it to private. The guest reads 0xbeef in its private address space. The host loses access. - Private-to-Shared (Bounce Buffer): The guest writes 0xbeef to private memory and converts it to shared. The host reads 0xbeef. > pKVM (ARM) is the first user of this policy. Since pKVM does not > protect memory with encryption, a content policy to preserve memory > will not will not involve any decryption. The guest will be able to > read what the host wrote with full content preservation. This is correct, but to be precise, I think it should explicitly mention Stage-2 page tables as the protection mechanism, maybe: Because pKVM protects private memory via Stage-2 page table isolation rather than hardware encryption, content preservation does not require cryptographic operations. The hypervisor (at EL2) simply transfers page ownership while retaining the data. Cheers, /fuad > For testing purposes, the KVM_X86_SW_PROTECTED_VM testing vehicle > will support this policy and the contents of converted memory will > be preserved. > > ``KVM_SET_MEMORY_ATTRIBUTES2_CONTENT_POLICY_NONE`` > > This is an explicit request that KVM provide no guarantees on memory > contents after conversion. Neither host nor guest should expect any > guarantees about the memory contents after conversion. > > For testing purposes, the KVM_X86_SW_PROTECTED_VM testing vehicle will > support this policy and every byte of converted memory will read > ``0xab``. > > >> See also: :ref: `KVM_SET_MEMORY_ATTRIBUTES`. > >> > > > > [...snip...] > >
