Re: [PATCH v2 00/24] KVM: arm64: Introduce pKVM shadow state at EL2

From: Sean Christopherson <seanjc@google.com>
To: Will Deacon <will@kernel.org>
Cc: kvmarm@lists.cs.columbia.edu, Ard Biesheuvel <ardb@kernel.org>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Andy Lutomirski <luto@amacapital.net>,
	Catalin Marinas <catalin.marinas@arm.com>,
	James Morse <james.morse@arm.com>,
	Chao Peng <chao.p.peng@linux.intel.com>,
	Quentin Perret <qperret@google.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Michael Roth <michael.roth@amd.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Fuad Tabba <tabba@google.com>,
	Oliver Upton <oliver.upton@linux.dev>,
	Marc Zyngier <maz@kernel.org>,
	kernel-team@android.com, kvm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 00/24] KVM: arm64: Introduce pKVM shadow state at EL2
Date: Wed, 6 Jul 2022 19:17:29 +0000	[thread overview]
Message-ID: <YsXfyVp6sg5XRVAp@google.com> (raw)
In-Reply-To: <20220630135747.26983-1-will@kernel.org>

On Thu, Jun 30, 2022, Will Deacon wrote:
> Hi everyone,
> 
> This series has been extracted from the pKVM base support series (aka
> "pKVM mega-patch") previously posted here:
> 
>   https://lore.kernel.org/kvmarm/20220519134204.5379-1-will@kernel.org/
> 
> Unlike that more comprehensive series, this one is fairly fundamental
> and does not introduce any new ABI commitments, leaving questions
> involving the management of guest private memory and the creation of
> protected VMs for future work. Instead, this series extends the pKVM EL2
> code so that it can dynamically instantiate and manage VM shadow
> structures without the host being able to access them directly. These
> shadow structures consist of a shadow VM, a set of shadow vCPUs and the
> stage-2 page-table and the pages used to hold them are returned to the
> host when the VM is destroyed.
> 
> The last patch is marked as RFC because, although it plumbs in the
> shadow state, it is woefully inefficient and copies to/from the host
> state on every vCPU run. Without the last patch, the new structures are
> unused but we move considerably closer to isolating guests from the
> host.

...

>  arch/arm64/include/asm/kvm_asm.h              |   6 +-
>  arch/arm64/include/asm/kvm_host.h             |  65 +++
>  arch/arm64/include/asm/kvm_hyp.h              |   3 +
>  arch/arm64/include/asm/kvm_pgtable.h          |   8 +
>  arch/arm64/include/asm/kvm_pkvm.h             |  38 ++
>  arch/arm64/kernel/image-vars.h                |  15 -
>  arch/arm64/kvm/arm.c                          |  40 +-
>  arch/arm64/kvm/hyp/hyp-constants.c            |   3 +
>  arch/arm64/kvm/hyp/include/nvhe/gfp.h         |   6 +-
>  arch/arm64/kvm/hyp/include/nvhe/mem_protect.h |  19 +-
>  arch/arm64/kvm/hyp/include/nvhe/memory.h      |  26 +-
>  arch/arm64/kvm/hyp/include/nvhe/mm.h          |  18 +-
>  arch/arm64/kvm/hyp/include/nvhe/pkvm.h        |  70 +++
>  arch/arm64/kvm/hyp/include/nvhe/spinlock.h    |  10 +-
>  arch/arm64/kvm/hyp/nvhe/cache.S               |  11 +
>  arch/arm64/kvm/hyp/nvhe/hyp-main.c            | 105 +++-
>  arch/arm64/kvm/hyp/nvhe/hyp-smp.c             |   2 +
>  arch/arm64/kvm/hyp/nvhe/mem_protect.c         | 456 +++++++++++++++++-
>  arch/arm64/kvm/hyp/nvhe/mm.c                  | 136 +++++-
>  arch/arm64/kvm/hyp/nvhe/page_alloc.c          |  42 +-
>  arch/arm64/kvm/hyp/nvhe/pkvm.c                | 438 +++++++++++++++++
>  arch/arm64/kvm/hyp/nvhe/setup.c               |  96 ++--
>  arch/arm64/kvm/hyp/pgtable.c                  |   9 +
>  arch/arm64/kvm/mmu.c                          |  26 +
>  arch/arm64/kvm/pkvm.c                         | 121 ++++-
>  25 files changed, 1625 insertions(+), 144 deletions(-)
>  create mode 100644 arch/arm64/kvm/hyp/include/nvhe/pkvm.h

The lack of documentation and the rather terse changelogs make this really hard
to review for folks that aren't intimately familiar with pKVM.  I have a decent
idea of the end goal of "shadowing", but that's mostly because of my involvement in
similar x86 projects.  Nothing in the changelogs ever explains _why_ pKVM uses
shadows.

I put "shadowing" in quotes because if the unstrusted host is aware that the VM
and vCPU it is manipulating aren't the "real" VMs/vCPUs, and there is an explicit API
between the untrusted host and pKVM for creating/destroying VMs/vCPUs, then I would
argue that it's not truly shadowing, especially if pKVM uses data/values verbatim
and only verifies correctness/safety.  It's definitely a nit, but for future readers
I think overloading "shadowing" could be confusing.

And beyond the basics, IMO pKVM needs a more formal definition of exactly what
guest state is protected/hidden from the untrusted host.  Peeking at the mega series,
there are a huge pile of patches that result in "gradual reduction of EL2 trust in
host data", but I couldn't any documentation that defines what that end result is.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel