[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest
From: |
Sean Christopherson |
Subject: |
Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory |
Date: |
Mon, 28 Mar 2022 17:13:10 +0000 |
On Thu, Mar 24, 2022, Quentin Perret wrote:
> For Protected KVM (and I suspect most other confidential computing
> solutions), guests have the ability to share some of their pages back
> with the host kernel using a dedicated hypercall. This is necessary
> for e.g. virtio communications, so these shared pages need to be mapped
> back into the VMM's address space. I'm a bit confused about how that
> would work with the approach proposed here. What is going to be the
> approach for TDX?
>
> It feels like the most 'natural' thing would be to have a KVM exit
> reason describing which pages have been shared back by the guest, and to
> then allow the VMM to mmap those specific pages in response in the
> memfd. Is this something that has been discussed or considered?
The proposed solution is to exit to userspace with a new exit reason,
KVM_EXIT_MEMORY_ERROR,
when the guest makes the hypercall to request conversion[1]. The private fd
itself
will never allow mapping memory into userspace, instead userspace will need to
punch
a hole in the private fd backing store. The absense of a valid mapping in the
private
fd is how KVM detects that a pfn is "shared" (memslots without a private fd are
always
shared)[2].
The key point is that KVM never decides to convert between shared and private,
it's
always a userspace decision. Like normal memslots, where userspace has full
control
over what gfns are a valid, this gives userspace full control over whether a
gfn is
shared or private at any given time.
Another important detail is that this approach means the kernel and KVM treat
the
shared backing store and private backing store as independent, albeit related,
entities. This is very deliberate as it makes it easier to reason about what is
and isn't allowed/required. E.g. the kernel only needs to handle freeing
private
memory, there is no special handling for conversion to shared because no such
path
exists as far as host pfns are concerned. And userspace doesn't need any new
"rules"
for protecting itself against a malicious guest, e.g. userspace already needs to
ensure that it has a valid mapping prior to accessing guest memory (or be able
to
handle any resulting signals). A malicious guest can DoS itself by instructing
userspace to communicate over memory that is currently mapped private, but there
are no new novel attack vectors from the host's perspective as coercing the host
into accessing an invalid mapping after shared=>private conversion is just a
variant
of a use-after-free.
One potential conversions that's TBD (at least, I think it is, I haven't read
through
this most recent version) is how to support populating guest private memory with
non-zero data, e.g. to allow in-place conversion of the initial guest firmware
instead
of having to an extra memcpy().
[1] KVM will also exit to userspace with the same info on "implicit"
conversions,
i.e. if the guest accesses the "wrong" GPA. Neither SEV-SNP nor TDX mandate
explicit conversions in their guest<->host ABIs, so KVM has to support
implicit
conversions :-/
[2] Ideally (IMO), KVM would require userspace to completely remove the private
memslot,
but that's too slow due to use of SRCU in both KVM and userspace (QEMU at
least uses
SRCU for memslot changes).
- [PATCH v5 10/13] KVM: Register private memslot to memory backing store, (continued)
- [PATCH v5 10/13] KVM: Register private memslot to memory backing store, Chao Peng, 2022/03/10
- [PATCH v5 09/13] KVM: Handle page fault for private memory, Chao Peng, 2022/03/10
- [PATCH v5 12/13] KVM: Expose KVM_MEM_PRIVATE, Chao Peng, 2022/03/10
- [PATCH v5 11/13] KVM: Zap existing KVM mappings when pages changed in the private fd, Chao Peng, 2022/03/10
- [PATCH v5 13/13] memfd_create.2: Describe MFD_INACCESSIBLE flag, Chao Peng, 2022/03/10
- Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory, Quentin Perret, 2022/03/24
- Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory,
Sean Christopherson <=
- Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory, Quentin Perret, 2022/03/28
- Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory, Sean Christopherson, 2022/03/28
- Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory, Quentin Perret, 2022/03/29
- Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory, Steven Price, 2022/03/30
- Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory, Quentin Perret, 2022/03/30
- Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory, Sean Christopherson, 2022/03/30
- Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory, Andy Lutomirski, 2022/03/31
- Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory, Sean Christopherson, 2022/03/30
Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory, Andy Lutomirski, 2022/03/28