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

[David Hildenbrand]

> > > Well not necessarily, but it depends how clever we want to get.  If
> > > you look over on the OVMF/edk2 list, there's a proposal to do guest
> > > migration via a mirror VM that invokes a co-routine embedded in the
> > > OVMF binary:
> >
> > Yes, I heard of that. "Interesting" design.
>
> Heh, well what other suggestion do you have?  The problem is there
> needs to be code somewhere to perform some operations that's trusted by
> both the guest and the host.  The only element for a confidential VM
> that has this shared trust is the OVMF firmware, so it seems logical to
> use it.

<offtopic>

Let me put it this way: I worked with another architecture that doesn't 
fault on access of a secure page, but instead automatically 
exports/encrypts it so it can be swapped. It doesn't send a MCE and 
kills the host. It doesn't require fancy code in the guest firmware to 
export a page.

The code runs in the ultravisor -- yes, I'm talking about s390x. Now, I 
am not an expert on all of the glory details of TDX, SEV, ... to say 
which attack surface they introduced with that design, and if it can't 
be mitigated. I can only assume that there are real reasons (e.g., 
supporting an ultravisor is problematic, patents? ;) ) why x86-64 is 
different.

So whenever I see something really complicated to work around such 
issues, it feels to me like a hardware/platform limitation is making our 
life hard and forces us to come up with such "interesting" designs.

Sure, it's logical in this context, but it feels like "The house doesn't 
have a door, so I'll have to climb through the window.". It gets the job 
done but isn't ideally what you'd want to have. If you understand what I 
am trying to say :)

</offtopic>

> > > https://patchew.org/EDK2/20210818212048.162626-1-tobin@xxxxxxxxxxxxx/
> > >
> > > This gives us a page encryption mechanism that's provided by the
> > > host but accepted via the guest using attestation, meaning we have
> > > a mutually trusted piece of code that can use to extract encrypted
> > > pages. It does seem it could be enhanced to do swapping for us as
> > > well if that's a road we want to go down?
> >
> > Right, but that's than no longer ballooning, unless I am missing
> > something important. You'd ask the guest to export/import, and you
> > can trust it. But do we want to call something like that out of
> > random kernel context when swapping/writeback, ...? Hard to tell.
> > Feels like it won't win in a beauty contest.
>
> What I was thinking is that OVMF can emulate devices in this trusted
> code ... another potential use for it is a trusted vTPM for SEV-SNP so
> we can do measured boot.  To use it we'd give the guest kernel some
> type of virtual swap driver that attaches to this OVMF device.  I
> suppose by the time we've done this, it really does look like a
> balloon, but I'd like to think of it more as a paravirt memory
> controller since it might be used to make a guest more co-operative in
> a host overcommit situation.
>
> That's not to say we *should* do this, merely that it doesn't have to
> look like a pig with lipstick.

It's an interesting approach: it would essentially mean that the OVMF 
would swap pages out to some virtual device and then essentially 
"inflate" the pages like a balloon. Still, it doesn't sound like 
something you want to trigger from actual kernel context when actually 
swapping in the kernel. It would much rather be something like other 
balloon implementations: completely controlled by user space.

So yes, "doesn't look like a pig with lipstick", but still compared to 
proper in-kernel swapping, looks like a workaround.

--
Thanks,

David / dhildenb