All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Suzuki K Poulose" <suzuki.poulose@arm.com>
Cc: kvmarm@lists.linux.dev, "Marc Zyngier" <maz@kernel.org>,
	kvm@vger.kernel.org, "Oliver Upton" <oupton@kernel.org>
Subject: Re: [PATCH v20 18/22] KVM: arm64: CCA: Don't expose unsupported capabilities for realm guests
Date: Thu, 24 Sep 2026 16:25:56 +0000	[thread overview]
Message-ID: <20260924162557.766101F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260924160504.853911-19-suzuki.poulose@arm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] kvm: arm64: CCA: Realm VCPU features bypass capability allowlist
--

commit e303d487e75069060645d8d27a0d2607328fb9fc
Author: Suzuki K Poulose <suzuki.poulose@arm.com>

KVM: arm64: CCA: Don't expose unsupported capabilities for realm guests

Limit the capabilities that are allowed for Realm VMs. Similarly block
the vm_ioctls backed by the capabilities.

Repurpose the kvm_pkvm_ioctl_allowed() to support both pKVM and Realm
ioctls. Rename the helper to kvm_vm_ioctl_allowed() and move it
into arch/arm64/kvm/arm.c. Also add a generic kvm_vm_ext_allowed()
to handle pKVM and Realm capability filtering and route them accordingly.

> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 0e77f59ded6d9..106b52e556e20 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
[ ... ]
> @@ -136,6 +136,49 @@ int kvm_arch_vcpu_should_kick(struct kvm_vcpu *vcpu)
>  	return kvm_vcpu_exiting_guest_mode(vcpu) == IN_GUEST_MODE;
>  }
>  
> +static inline bool kvm_vm_ext_allowed(struct kvm *kvm, long ext)
> +{
> +	/*
> +	 * We could be called with kvm as NULL, so can't use kvm_vm_* for pKVM
> +	 * flavors
> +	 */
> +	if (is_protected_kvm_enabled())
> +		return kvm_pkvm_ext_allowed(kvm, ext);
> +	else if (kvm && kvm_vm_is_realm(kvm))
> +		return kvm_realm_ext_allowed(ext);
> +	else
> +		return true;
> +}

[Severity: High]
While this patch correctly limits VM-level capabilities and ioctls for Realm
VMs, does it miss restricting VCPU-level features during initialization?

Looking at kvm_vcpu_init_check_features() in arch/arm64/kvm/arm.c:

static int kvm_vcpu_init_check_features(struct kvm_vcpu *vcpu,
					const struct kvm_vcpu_init *init)
{
	unsigned long features = init->features[0];
	...
	if (features & ~system_supported_vcpu_features())
		return -EINVAL;

Since system_supported_vcpu_features() only checks global host capabilities,
can a malicious userspace process managing the VM enable restricted VCPU
features (such as KVM_ARM_VCPU_PMU_V3 or KVM_ARM_VCPU_EL1_32BIT) on a Realm
VCPU?

If userspace creates a Realm VM and VCPU, then invokes the KVM_ARM_VCPU_INIT
ioctl with restricted features set in init.features[0], this could activate
host KVM emulation logic for a Realm. Would this break the intended isolation
boundary and lead to inconsistent state or host/RMM crashes when KVM attempts
to emulate hardware for a Realm managed by the RMM?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260924160504.853911-1-suzuki.poulose@arm.com?part=18

  reply	other threads:[~2026-09-24 16:25 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-24 16:04 [PATCH v20 00/22] KVM: arm64: CCA: Add basic plumbing for Realms Suzuki K Poulose
2026-09-24 16:04 ` [PATCH v20 01/22] KVM: arm64: protected VM: Handle user writes to CNTVCT_EL0/CNTPCT_EL0 Suzuki K Poulose
2026-09-24 16:04 ` [PATCH v20 02/22] KVM: arm64: Disable Steal time accounting for protected guests Suzuki K Poulose
2026-09-24 16:04 ` [PATCH v20 03/22] KVM: arm64: Include kvm_emulate.h in kvm/arm_psci.h Suzuki K Poulose
2026-09-24 16:04 ` [PATCH v20 04/22] KVM: arm64: Avoid including linux/kvm_host.h in kvm_pgtable.h Suzuki K Poulose
2026-09-24 16:04 ` [PATCH v20 05/22] KVM: arm64: Track the type of VM in kvm_arch Suzuki K Poulose
2026-09-24 16:04 ` [PATCH v20 06/22] KVM: arm64: Don't call vcpu_set_pauth_traps for pKVM host Suzuki K Poulose
2026-09-24 16:04 ` [PATCH v20 07/22] KVM: arm64: Refactor the vcpu_load to allow for VM specific callbacks Suzuki K Poulose
2026-09-24 16:04 ` [PATCH v20 08/22] KVM: arm64: Add vcpu load/put call backs for flavors Suzuki K Poulose
2026-09-24 16:04 ` [PATCH v20 09/22] KVM: arm64: Reuse kvm_stage2_unmap_range in kvm_unmap_gfn_range Suzuki K Poulose
2026-09-24 16:04 ` [PATCH v20 10/22] KVM: arm64: Add VM specific callback for S2 MMU operations Suzuki K Poulose
2026-09-24 16:04 ` [PATCH v20 11/22] KVM: arm64: Use a local kvm pointer in kvm_handle_guest_abort() Suzuki K Poulose
2026-09-24 16:04 ` [PATCH v20 12/22] KVM: arm64: Abstract out memory abort handling Suzuki K Poulose
2026-09-24 16:04 ` [PATCH v20 13/22] KVM: arm64: Mandate VGIC v3 for pKVM VMs and Realms Suzuki K Poulose
2026-09-24 16:04 ` [PATCH v20 14/22] KVM: arm64: CCA: Add a new mode for supporting Realm guests Suzuki K Poulose
2026-09-24 16:04 ` [PATCH v20 15/22] KVM: arm64: CCA: Add VCPU load/put for Realms Suzuki K Poulose
2026-09-24 16:04 ` [PATCH v20 16/22] KVM: arm64: CCA: Add bare minimal S2 operations for Realm Suzuki K Poulose
2026-09-24 16:04 ` [PATCH v20 17/22] KVM: arm64: CCA: Introduce Realms Suzuki K Poulose
2026-09-24 16:05 ` [PATCH v20 18/22] KVM: arm64: CCA: Don't expose unsupported capabilities for realm guests Suzuki K Poulose
2026-09-24 16:25   ` sashiko-bot [this message]
2026-09-29 13:25     ` Suzuki K Poulose
2026-09-24 16:05 ` [PATCH v20 19/22] KVM: arm64: CCA: WARN on injected undef exceptions Suzuki K Poulose
2026-09-24 16:05 ` [PATCH v20 20/22] KVM: arm64: CCA: Support timers in realm RECs Suzuki K Poulose
2026-09-24 16:05 ` [PATCH v20 21/22] KVM: arm64: CCA: Expose SVE VL register before VCPU finalization Suzuki K Poulose
2026-09-24 16:05 ` [PATCH v20 22/22] KVM: arm64: CCA: Control user register access for Realms Suzuki K Poulose
2026-10-01 15:53   ` Catalin Marinas
2026-10-01 16:37     ` Suzuki K Poulose

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=20260924162557.766101F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=maz@kernel.org \
    --cc=oupton@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=suzuki.poulose@arm.com \
    /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.