Messages in this thread | | | From | Andy Lutomirski <> | Date | Mon, 17 Jun 2019 18:40:31 -0700 | Subject | Re: [PATCH, RFC 45/62] mm: Add the encrypt_mprotect() system call for MKTME |
| |
On Mon, Jun 17, 2019 at 6:34 PM Lendacky, Thomas <Thomas.Lendacky@amd.com> wrote: > > On 6/17/19 6:59 PM, Kai Huang wrote: > > On Mon, 2019-06-17 at 11:27 -0700, Dave Hansen wrote:
> > > > And yes from my reading (better to have AMD guys to confirm) SEV guest uses anonymous memory, but it > > also pins all guest memory (by calling GUP from KVM -- SEV specifically introduced 2 KVM ioctls for > > this purpose), since SEV architecturally cannot support swapping, migraiton of SEV-encrypted guest > > memory, because SME/SEV also uses physical address as "tweak", and there's no way that kernel can > > get or use SEV-guest's memory encryption key. In order to swap/migrate SEV-guest memory, we need SGX > > EPC eviction/reload similar thing, which SEV doesn't have today. > > Yes, all the guest memory is currently pinned by calling GUP when creating > an SEV guest.
Ick.
What happens if QEMU tries to read the memory? Does it just see ciphertext? Is cache coherency lost if QEMU writes it?
| |