Re: [RFC] KVM: mm: fd-based approach for supporting KVM guest private memory

On 01.09.21 06:58, Andy Lutomirski wrote:

On Tue, Aug 31, 2021, at 12:07 PM, David Hildenbrand wrote:

quoted

On 28.08.21 00:18, Sean Christopherson wrote:

quoted

On Thu, Aug 26, 2021, David Hildenbrand wrote:

quoted

You'll end up with a VMA that corresponds to the whole file in a single
process only, and that cannot vanish, not even in parts.

How would userspace tell the kernel to free parts of memory that it doesn't want
assigned to the guest, e.g. to free memory that the guest has converted to
not-private?

I'd guess one possibility could be fallocate(FALLOC_FL_PUNCH_HOLE).

Questions are: when would it actually be allowed to perform such a
destructive operation? Do we have to protect from that? How would KVM
protect from user space replacing private pages by shared pages in any
of the models we discuss?

What do you mean?  If userspace maliciously replaces a shared page by a private page, then the guest crashes.

Assume we have private pages in a fd and fallocate(FALLOC_FL_PUNCH_HOLE) 
random pages the guest is still using. If we "only" crash the guest, 
everything is fine.

(The actual meaning here is a bit different on SNP-ES vs TDX.  In SNP-ES, a given GPA can be shared, private, or nonexistent.  A guest accesses it with a special bit set in the guest page tables to indicate whether it expects shared or private, and the CPU will produce an appropriate error if the bit doesn't match the page.

Rings a bell, thanks for reminding me.

  In TDX, there is actually an entirely separate shared vs private 
address space, and, in theory, a given "GPA" can exist as shared and as 
private at once.  The full guest n-bit GPA plus the shared/private bit 
is logically an N+1 bit address, and it's possible to map all of it at 
once, half shared, and half private.  In practice, the defined 
guest->host APIs don't really support that usage.

Thanks, that explains a lot.

-- 
Thanks,

David / dhildenb