[RFC PATCH v2 0/6] KVM: arm64: Userspace SMCCC call filtering

From: Oliver Upton <oliver.upton@linux.dev>
To: Marc Zyngier <maz@kernel.org>
Cc: James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	kvmarm@lists.linux.dev, Akihiko Odaki <akihiko.odaki@daynix.com>,
	Zenghui Yu <yuzenghui@huawei.com>,
	Raghavendra Rao Ananta <rananta@google.com>,
	linux-arm-kernel@lists.infradead.org,
	Salil Mehta <salil.mehta@huawei.com>,
	Oliver Upton <oliver.upton@linux.dev>
Subject: [RFC PATCH v2 0/6] KVM: arm64: Userspace SMCCC call filtering
Date: Sat, 11 Feb 2023 01:37:53 +0000	[thread overview]
Message-ID: <20230211013759.3556016-1-oliver.upton@linux.dev> (raw)

The Arm SMCCC is rather prescriptive in regards to the allocation of
SMCCC function ID ranges. Many of the hypercall ranges have an
associated specification from Arm (FF-A, PSCI, SDEI, etc.) with some
room for vendor-specific implementations.

The ever-expanding SMCCC surface leaves a lot of work within KVM for
providing new features. Furthermore, KVM implements its own
vendor-specific ABI, with little room for other implementations (like
Hyper-V, for example).

Not only that, it would appear that vCPU hotplug [1] has a legitimate
use case for something like this, sending PSCI calls to userspace (where
they should have gone in the first place).

=> We have these new hypercall bitmap registers, why not use that?

The hypercall bitmap registers aren't necessarily aimed at the same
problem. The bitmap registers allow a VMM to preserve the ABI the guest
gets from KVM by default when migrating between hosts. By default KVM
exposes the entire feature set to the guest, whereas user SMCCC calls
need explicit opt-in from userspace.

Applies to 6.2-rc3.

TODO:
 - Reject the ranges of hypercalls we don't want userspace to handle.
   Spectre crud mainly, any others?

   I plan on using the invariant of the maple tree to reject filters
   that intersect with a reserved range.

 - Should exits for SMC calls have the PC pre-incremented to align with
   HVC? Go read the comment in handle_smc() if you aren't following.

   I think the answer is 'yes', but opinions welcome as always :)

 - This series unifies the SMCCC space for HVCs and SMCs but this
   requires a lot more thought. Otherwise, we can add support for two
   separate namespaces.

 - Testing! I only got as far as compiling this on my machine. At
   minimum a decent selftest is requried considering the UAPI here is
   rather involved.

RFC v1 -> v2:
 - Use a range-based interface instead of filtering entire services
 - Stop using the braindead term of 'trapping' in relation to userspace.

Oliver Upton (6):
  KVM: arm64: Add a helper to check if a VM has ran once
  KVM: arm64: Add vm fd device attribute accessors
  KVM: arm64: Refactor hvc filtering to support different actions
  KVM: arm64: Use a maple tree to represent the SMCCC filter
  KVM: arm64: Add support for KVM_EXIT_HYPERCALL
  KVM: arm64: Indroduce support for userspace SMCCC filtering

 Documentation/virt/kvm/api.rst        |  24 +++-
 Documentation/virt/kvm/devices/vm.rst |  67 ++++++++++
 arch/arm64/include/asm/kvm_host.h     |   8 +-
 arch/arm64/include/uapi/asm/kvm.h     |  31 +++++
 arch/arm64/kvm/arm.c                  |  35 +++++
 arch/arm64/kvm/handle_exit.c          |  12 +-
 arch/arm64/kvm/hypercalls.c           | 176 +++++++++++++++++++++++++-
 arch/arm64/kvm/pmu-emul.c             |   4 +-
 include/kvm/arm_hypercalls.h          |   5 +
 include/uapi/linux/kvm.h              |   2 +-
 10 files changed, 350 insertions(+), 14 deletions(-)

base-commit: b7bfaa761d760e72a969d116517eaa12e404c262
-- 
2.39.1.581.gbfd45094c4-goog

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