Re: [PATCH v2 0/3] KVM: arm64: support MTE in protected VMs

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