From: Cornelia Huck <cohuck@redhat.com>
To: Peter Collingbourne <pcc@google.com>, kvmarm@lists.cs.columbia.edu
Cc: Catalin Marinas <catalin.marinas@arm.com>,
kvm@vger.kernel.org, Marc Zyngier <maz@kernel.org>,
Andy Lutomirski <luto@amacapital.net>,
Will Deacon <will@kernel.org>,
Evgenii Stepanov <eugenis@google.com>,
Michael Roth <michael.roth@amd.com>,
Chao Peng <chao.p.peng@linux.intel.com>,
Peter Collingbourne <pcc@google.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 0/3] KVM: arm64: support MTE in protected VMs
Date: Tue, 19 Jul 2022 16:50:08 +0200 [thread overview]
Message-ID: <877d49p36n.fsf@redhat.com> (raw)
In-Reply-To: <20220708212106.325260-1-pcc@google.com>
On Fri, Jul 08 2022, Peter Collingbourne <pcc@google.com> wrote:
> Hi,
>
> This patch series contains a proposed extension to pKVM that allows MTE
> to be exposed to the protected guests. It is based on the base pKVM
> series previously sent to the list [1] and later rebased to 5.19-rc3
> and uploaded to [2].
>
> This series takes precautions against host compromise of the guests
> via direct access to their tag storage, by preventing the host from
> accessing the tag storage via stage 2 page tables. The device tree
> must describe the physical memory address of the tag storage, if any,
> and the memory nodes must declare that the tag storage location is
> described. Otherwise, the MTE feature is disabled in protected guests.
>
> Now that we can easily do so, we also prevent the host from accessing
> any unmapped reserved-memory regions without a driver, as the host
> has no business accessing that memory.
>
> A proposed extension to the devicetree specification is available at
> [3], a patched version of QEMU that produces the required device tree
> nodes is available at [4] and a patched version of the crosvm hypervisor
> that enables MTE is available at [5].
I'm unsure how this is supposed to work with QEMU + KVM, as your QEMU
patch adds mte-alloc properties to regions that are exposed as a
separate address space (which will not work with KVM). Is the magic in
that new shared section?
>
> v2:
> - refcount the PTEs owned by NOBODY
>
> [1] https://lore.kernel.org/all/20220519134204.5379-1-will@kernel.org/
> [2] https://android-kvm.googlesource.com/linux/ for-upstream/pkvm-base-v2
> [3] https://github.com/pcc/devicetree-specification mte-alloc
> [4] https://github.com/pcc/qemu mte-shared-alloc
> [5] https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3719324
>
> Peter Collingbourne (3):
> KVM: arm64: add a hypercall for disowning pages
> KVM: arm64: disown unused reserved-memory regions
> KVM: arm64: allow MTE in protected VMs if the tag storage is known
>
> arch/arm64/include/asm/kvm_asm.h | 1 +
> arch/arm64/include/asm/kvm_host.h | 6 ++
> arch/arm64/include/asm/kvm_pkvm.h | 4 +-
> arch/arm64/kernel/image-vars.h | 3 +
> arch/arm64/kvm/arm.c | 83 ++++++++++++++++++-
> arch/arm64/kvm/hyp/include/nvhe/mem_protect.h | 1 +
> arch/arm64/kvm/hyp/include/nvhe/pkvm.h | 1 +
> arch/arm64/kvm/hyp/nvhe/hyp-main.c | 9 ++
> arch/arm64/kvm/hyp/nvhe/mem_protect.c | 11 +++
> arch/arm64/kvm/hyp/nvhe/pkvm.c | 8 +-
> arch/arm64/kvm/mmu.c | 4 +-
> 11 files changed, 123 insertions(+), 8 deletions(-)
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: Cornelia Huck <cohuck@redhat.com>
To: Peter Collingbourne <pcc@google.com>, kvmarm@lists.cs.columbia.edu
Cc: Peter Collingbourne <pcc@google.com>,
Marc Zyngier <maz@kernel.org>,
kvm@vger.kernel.org, Andy Lutomirski <luto@amacapital.net>,
linux-arm-kernel@lists.infradead.org,
Michael Roth <michael.roth@amd.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Chao Peng <chao.p.peng@linux.intel.com>,
Will Deacon <will@kernel.org>,
Evgenii Stepanov <eugenis@google.com>
Subject: Re: [PATCH v2 0/3] KVM: arm64: support MTE in protected VMs
Date: Tue, 19 Jul 2022 16:50:08 +0200 [thread overview]
Message-ID: <877d49p36n.fsf@redhat.com> (raw)
In-Reply-To: <20220708212106.325260-1-pcc@google.com>
On Fri, Jul 08 2022, Peter Collingbourne <pcc@google.com> wrote:
> Hi,
>
> This patch series contains a proposed extension to pKVM that allows MTE
> to be exposed to the protected guests. It is based on the base pKVM
> series previously sent to the list [1] and later rebased to 5.19-rc3
> and uploaded to [2].
>
> This series takes precautions against host compromise of the guests
> via direct access to their tag storage, by preventing the host from
> accessing the tag storage via stage 2 page tables. The device tree
> must describe the physical memory address of the tag storage, if any,
> and the memory nodes must declare that the tag storage location is
> described. Otherwise, the MTE feature is disabled in protected guests.
>
> Now that we can easily do so, we also prevent the host from accessing
> any unmapped reserved-memory regions without a driver, as the host
> has no business accessing that memory.
>
> A proposed extension to the devicetree specification is available at
> [3], a patched version of QEMU that produces the required device tree
> nodes is available at [4] and a patched version of the crosvm hypervisor
> that enables MTE is available at [5].
I'm unsure how this is supposed to work with QEMU + KVM, as your QEMU
patch adds mte-alloc properties to regions that are exposed as a
separate address space (which will not work with KVM). Is the magic in
that new shared section?
>
> v2:
> - refcount the PTEs owned by NOBODY
>
> [1] https://lore.kernel.org/all/20220519134204.5379-1-will@kernel.org/
> [2] https://android-kvm.googlesource.com/linux/ for-upstream/pkvm-base-v2
> [3] https://github.com/pcc/devicetree-specification mte-alloc
> [4] https://github.com/pcc/qemu mte-shared-alloc
> [5] https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3719324
>
> Peter Collingbourne (3):
> KVM: arm64: add a hypercall for disowning pages
> KVM: arm64: disown unused reserved-memory regions
> KVM: arm64: allow MTE in protected VMs if the tag storage is known
>
> arch/arm64/include/asm/kvm_asm.h | 1 +
> arch/arm64/include/asm/kvm_host.h | 6 ++
> arch/arm64/include/asm/kvm_pkvm.h | 4 +-
> arch/arm64/kernel/image-vars.h | 3 +
> arch/arm64/kvm/arm.c | 83 ++++++++++++++++++-
> arch/arm64/kvm/hyp/include/nvhe/mem_protect.h | 1 +
> arch/arm64/kvm/hyp/include/nvhe/pkvm.h | 1 +
> arch/arm64/kvm/hyp/nvhe/hyp-main.c | 9 ++
> arch/arm64/kvm/hyp/nvhe/mem_protect.c | 11 +++
> arch/arm64/kvm/hyp/nvhe/pkvm.c | 8 +-
> arch/arm64/kvm/mmu.c | 4 +-
> 11 files changed, 123 insertions(+), 8 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Cornelia Huck <cohuck@redhat.com>
To: Peter Collingbourne <pcc@google.com>, kvmarm@lists.cs.columbia.edu
Cc: Peter Collingbourne <pcc@google.com>,
Marc Zyngier <maz@kernel.org>,
kvm@vger.kernel.org, Andy Lutomirski <luto@amacapital.net>,
linux-arm-kernel@lists.infradead.org,
Michael Roth <michael.roth@amd.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Chao Peng <chao.p.peng@linux.intel.com>,
Will Deacon <will@kernel.org>,
Evgenii Stepanov <eugenis@google.com>
Subject: Re: [PATCH v2 0/3] KVM: arm64: support MTE in protected VMs
Date: Tue, 19 Jul 2022 16:50:08 +0200 [thread overview]
Message-ID: <877d49p36n.fsf@redhat.com> (raw)
In-Reply-To: <20220708212106.325260-1-pcc@google.com>
On Fri, Jul 08 2022, Peter Collingbourne <pcc@google.com> wrote:
> Hi,
>
> This patch series contains a proposed extension to pKVM that allows MTE
> to be exposed to the protected guests. It is based on the base pKVM
> series previously sent to the list [1] and later rebased to 5.19-rc3
> and uploaded to [2].
>
> This series takes precautions against host compromise of the guests
> via direct access to their tag storage, by preventing the host from
> accessing the tag storage via stage 2 page tables. The device tree
> must describe the physical memory address of the tag storage, if any,
> and the memory nodes must declare that the tag storage location is
> described. Otherwise, the MTE feature is disabled in protected guests.
>
> Now that we can easily do so, we also prevent the host from accessing
> any unmapped reserved-memory regions without a driver, as the host
> has no business accessing that memory.
>
> A proposed extension to the devicetree specification is available at
> [3], a patched version of QEMU that produces the required device tree
> nodes is available at [4] and a patched version of the crosvm hypervisor
> that enables MTE is available at [5].
I'm unsure how this is supposed to work with QEMU + KVM, as your QEMU
patch adds mte-alloc properties to regions that are exposed as a
separate address space (which will not work with KVM). Is the magic in
that new shared section?
>
> v2:
> - refcount the PTEs owned by NOBODY
>
> [1] https://lore.kernel.org/all/20220519134204.5379-1-will@kernel.org/
> [2] https://android-kvm.googlesource.com/linux/ for-upstream/pkvm-base-v2
> [3] https://github.com/pcc/devicetree-specification mte-alloc
> [4] https://github.com/pcc/qemu mte-shared-alloc
> [5] https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3719324
>
> Peter Collingbourne (3):
> KVM: arm64: add a hypercall for disowning pages
> KVM: arm64: disown unused reserved-memory regions
> KVM: arm64: allow MTE in protected VMs if the tag storage is known
>
> arch/arm64/include/asm/kvm_asm.h | 1 +
> arch/arm64/include/asm/kvm_host.h | 6 ++
> arch/arm64/include/asm/kvm_pkvm.h | 4 +-
> arch/arm64/kernel/image-vars.h | 3 +
> arch/arm64/kvm/arm.c | 83 ++++++++++++++++++-
> arch/arm64/kvm/hyp/include/nvhe/mem_protect.h | 1 +
> arch/arm64/kvm/hyp/include/nvhe/pkvm.h | 1 +
> arch/arm64/kvm/hyp/nvhe/hyp-main.c | 9 ++
> arch/arm64/kvm/hyp/nvhe/mem_protect.c | 11 +++
> arch/arm64/kvm/hyp/nvhe/pkvm.c | 8 +-
> arch/arm64/kvm/mmu.c | 4 +-
> 11 files changed, 123 insertions(+), 8 deletions(-)
next prev parent reply other threads:[~2022-07-19 14:50 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-08 21:21 [PATCH v2 0/3] KVM: arm64: support MTE in protected VMs Peter Collingbourne
2022-07-08 21:21 ` Peter Collingbourne
2022-07-08 21:21 ` Peter Collingbourne
2022-07-08 21:21 ` [PATCH v2 1/3] KVM: arm64: add a hypercall for disowning pages Peter Collingbourne
2022-07-08 21:21 ` Peter Collingbourne
2022-07-08 21:21 ` Peter Collingbourne
2022-07-08 21:21 ` [PATCH v2 2/3] KVM: arm64: disown unused reserved-memory regions Peter Collingbourne
2022-07-08 21:21 ` Peter Collingbourne
2022-07-08 21:21 ` Peter Collingbourne
2022-07-08 21:21 ` [PATCH v2 3/3] KVM: arm64: allow MTE in protected VMs if the tag storage is known Peter Collingbourne
2022-07-08 21:21 ` Peter Collingbourne
2022-07-08 21:21 ` Peter Collingbourne
2022-07-09 1:50 ` [PATCH v2 0/3] KVM: arm64: support MTE in protected VMs Itaru Kitayama
2022-07-19 14:50 ` Cornelia Huck [this message]
2022-07-19 14:50 ` Cornelia Huck
2022-07-19 14:50 ` Cornelia Huck
2022-07-20 1:06 ` Peter Collingbourne
2022-07-20 1:06 ` Peter Collingbourne
2022-07-20 1:06 ` Peter Collingbourne
2022-07-20 16:21 ` Cornelia Huck
2022-07-20 16:21 ` Cornelia Huck
2022-07-20 16:21 ` Cornelia Huck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877d49p36n.fsf@redhat.com \
--to=cohuck@redhat.com \
--cc=catalin.marinas@arm.com \
--cc=chao.p.peng@linux.intel.com \
--cc=eugenis@google.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=luto@amacapital.net \
--cc=maz@kernel.org \
--cc=michael.roth@amd.com \
--cc=pcc@google.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.