Re: [RFC PATCH v1 00/26] KVM: Restricted mapping of guest_memfd at the host and pKVM/arm64 support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 28.02.24 15:01, Quentin Perret wrote:
On Wednesday 28 Feb 2024 at 11:12:18 (+0100), David Hildenbrand wrote:
So you don't need any guest_memfd games to protect from that -- and one
doesn't have to travel back in time to have memory that isn't
swappable/migratable and only comes in one page size.

[I'm not up-to-date which obscure corner-cases CCA requirement the s390x
implementation cannot fulfill -- like replacing pages in page tables and
such; I suspect pKVM also cannot cover all these corner-cases]

Thanks for this. I'll do some more reading on how things work with s390x.

Right, and of course, one key difference of course is that pKVM
doesn't encrypt anything, and only relies on stage-2 protection to
protect the guest.

I don't remember what exactly s390x does, but I recall that it might only
encrypt the memory content as it transitions a page from secure to
non-secure.

Something like that could also be implemented using pKVM (unless I am
missing something), but it might not be that trivial, of course :)

One of the complicated aspects of having the host migrate pages like so
is for the hypervisor to make sure the content of the page has not been
tempered with when the new page is re-mapped in the guest. That means
having additional tracking in the hypervisor of pages that have been
encrypted and returned to the host, indexed by IPA, with something like
a 'checksum' of some sort, which is non-trivial to do securely from a
cryptographic PoV.


I don't know what exactly s390x does, and how it does it -- and which CCA cases they can handle.

Details are scarce, for example:

https://www.ibm.com/docs/en/linux-on-systems?topic=virtualization-introducing-secure-execution-linux

I suspect they do it in some way you describe, and I fully agree with the "non-trivial" aspect :)

A simpler and secure way to do this is (I think) is to do
hypervisor-assisted migration. IOW, pKVM exposes a new migrate_page(ipa,
old_pa, new_pa) hypercall which Linux can call to migrate a page.
pKVM unmaps the new page from the host stage-2, unmap the old page from
guest stage-2, does the copy, wipes the old page, maps the pages in the
respective page-tables, and off we go. That way the content is never
visible to Linux and that avoids the problems I highlighted above by
construction. The downside is that it doesn't work for swapping, but
that is quite hard to do in general...

The main "problem" with that is that you still end up with these inaccessible pages, that require the use of guest_memfd for your in-place conversion requirement in the first place.

I'm sure at some point we'll see migration support also for TDX and friends. For pKVM it might be even easier to support.

--
Cheers,

David / dhildenb





[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux