[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC v2 PATCH 01/13] mm/shmem: Introduce F_SEAL_GUEST
From: |
Sean Christopherson |
Subject: |
Re: [RFC v2 PATCH 01/13] mm/shmem: Introduce F_SEAL_GUEST |
Date: |
Fri, 19 Nov 2021 22:21:39 +0000 |
On Fri, Nov 19, 2021, Jason Gunthorpe wrote:
> On Fri, Nov 19, 2021 at 07:18:00PM +0000, Sean Christopherson wrote:
> > No ideas for the kernel API, but that's also less concerning since
> > it's not set in stone. I'm also not sure that dedicated APIs for
> > each high-ish level use case would be a bad thing, as the semantics
> > are unlikely to be different to some extent. E.g. for the KVM use
> > case, there can be at most one guest associated with the fd, but
> > there can be any number of VFIO devices attached to the fd.
>
> Even the kvm thing is not a hard restriction when you take away
> confidential compute.
>
> Why can't we have multiple KVMs linked to the same FD if the memory
> isn't encrypted? Sure it isn't actually useful but it should work
> fine.
Hmm, true, but I want the KVM semantics to be 1:1 even if memory isn't
encrypted.
Encrypting memory with a key that isn't available to the host is necessary to
(mostly) remove the host kernel from the guest's TCB, but it's not necessary to
remove host userspace from the TCB. KVM absolutely can and should be able to do
that without relying on additional hardware/firmware. Ignoring attestation and
whether or not the guest fully trusts the host kernel, there's value in
preventing
a buggy or compromised userspace from attacking/corrupting the guest by
remapping
guest memory or by mapping the same memory into multiple guests.
> Supporting only one thing is just a way to avoid having a linked list
> of clients to broadcast invalidations too - for instance by using a
> standard notifier block...
It's not just avoiding the linked list, there's a trust element as well. E.g.
in
the scenario where a device can access a confidential VM's encrypted private
memory,
the guest is still the "owner" of the memory and needs to explicitly grant
access to
a third party, e.g. the device or perhaps another VM.
That said, I'm certainly not dead set on having "guest" in the name, nor am I
opposed to implementing multi-consumer support from the get-go so we don't end
up with a mess later on.
> Also, how does dirty tracking work on this memory?
For KVM usage, KVM would provide the dirty bit info. No idea how VFIO or other
use cases would work.
- Re: [RFC v2 PATCH 01/13] mm/shmem: Introduce F_SEAL_GUEST, (continued)
- Re: [RFC v2 PATCH 01/13] mm/shmem: Introduce F_SEAL_GUEST, Jason Gunthorpe, 2021/11/19
- Re: [RFC v2 PATCH 01/13] mm/shmem: Introduce F_SEAL_GUEST, David Hildenbrand, 2021/11/22
- Re: [RFC v2 PATCH 01/13] mm/shmem: Introduce F_SEAL_GUEST, Jason Gunthorpe, 2021/11/22
- Re: [RFC v2 PATCH 01/13] mm/shmem: Introduce F_SEAL_GUEST, David Hildenbrand, 2021/11/22
- Re: [RFC v2 PATCH 01/13] mm/shmem: Introduce F_SEAL_GUEST, Jason Gunthorpe, 2021/11/22
- Re: [RFC v2 PATCH 01/13] mm/shmem: Introduce F_SEAL_GUEST, David Hildenbrand, 2021/11/22
- Re: [RFC v2 PATCH 01/13] mm/shmem: Introduce F_SEAL_GUEST, Jason Gunthorpe, 2021/11/22
- Re: [RFC v2 PATCH 01/13] mm/shmem: Introduce F_SEAL_GUEST, David Hildenbrand, 2021/11/22
- Re: [RFC v2 PATCH 01/13] mm/shmem: Introduce F_SEAL_GUEST, Sean Christopherson, 2021/11/19
- Re: [RFC v2 PATCH 01/13] mm/shmem: Introduce F_SEAL_GUEST, Jason Gunthorpe, 2021/11/19
- Re: [RFC v2 PATCH 01/13] mm/shmem: Introduce F_SEAL_GUEST,
Sean Christopherson <=
- Re: [RFC v2 PATCH 01/13] mm/shmem: Introduce F_SEAL_GUEST, Jason Gunthorpe, 2021/11/19
- Re: [RFC v2 PATCH 01/13] mm/shmem: Introduce F_SEAL_GUEST, Sean Christopherson, 2021/11/19
- Re: [RFC v2 PATCH 01/13] mm/shmem: Introduce F_SEAL_GUEST, Jason Gunthorpe, 2021/11/20
- Re: [RFC v2 PATCH 01/13] mm/shmem: Introduce F_SEAL_GUEST, Paolo Bonzini, 2021/11/23
- Re: [RFC v2 PATCH 01/13] mm/shmem: Introduce F_SEAL_GUEST, Chao Peng, 2021/11/23
- Re: [RFC v2 PATCH 01/13] mm/shmem: Introduce F_SEAL_GUEST, David Hildenbrand, 2021/11/23
- Re: [RFC v2 PATCH 01/13] mm/shmem: Introduce F_SEAL_GUEST, Jason Gunthorpe, 2021/11/23
Re: [RFC v2 PATCH 01/13] mm/shmem: Introduce F_SEAL_GUEST, Paolo Bonzini, 2021/11/23
[RFC v2 PATCH 02/13] KVM: Add KVM_EXIT_MEMORY_ERROR exit, Chao Peng, 2021/11/19
[RFC v2 PATCH 03/13] KVM: Extend kvm_userspace_memory_region to support fd based memslot, Chao Peng, 2021/11/19