All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Fuad Tabba <tabba@google.com>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	oliver.upton@linux.dev, will@kernel.org, joey.gouly@arm.com,
	suzuki.poulose@arm.com, yuzenghui@huawei.com,
	catalin.marinas@arm.com, vladimir.murzin@arm.com
Subject: Re: [PATCH v5 5/9] KVM: arm64: Include VM type when checking VM capabilities in pKVM
Date: Wed, 26 Nov 2025 10:52:57 +0000	[thread overview]
Message-ID: <867bvdqd4m.wl-maz@kernel.org> (raw)
In-Reply-To: <20251118103807.707500-6-tabba@google.com>

On Tue, 18 Nov 2025 10:38:02 +0000,
Fuad Tabba <tabba@google.com> wrote:
> 
> Certian features and capabilities are restricted in protected mode. Most
> of these features are restricted only for protected VMs, but some
> are restricted for ALL VMs in protected mode.
> 
> Extend the pKVM capability check to pass the VM (kvm), and use that when
> determining supported features. Moreover, extend the check to disallow
> MTE for all VM types in protected mode.
> 
> Signed-off-by: Fuad Tabba <tabba@google.com>
> ---
>  arch/arm64/include/asm/kvm_pkvm.h | 10 ++++++----
>  arch/arm64/kvm/arm.c              |  4 ++--
>  arch/arm64/kvm/hyp/nvhe/pkvm.c    | 10 +++++-----
>  3 files changed, 13 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_pkvm.h b/arch/arm64/include/asm/kvm_pkvm.h
> index 08be89c95466..7195be508d99 100644
> --- a/arch/arm64/include/asm/kvm_pkvm.h
> +++ b/arch/arm64/include/asm/kvm_pkvm.h
> @@ -23,10 +23,12 @@ void pkvm_destroy_hyp_vm(struct kvm *kvm);
>  int pkvm_create_hyp_vcpu(struct kvm_vcpu *vcpu);
>  
>  /*
> - * This functions as an allow-list of protected VM capabilities.
> - * Features not explicitly allowed by this function are denied.
> + * Check whether the specific capability is allowed in pKVM.
> + *
> + * Certain features are allowed only for non-protected VMs in pKVM, which is why
> + * this takes the VM (kvm) as a parameter.
>   */
> -static inline bool kvm_pvm_ext_allowed(long ext)
> +static inline bool kvm_pkvm_ext_allowed(struct kvm *kvm, long ext)
>  {
>  	switch (ext) {
>  	case KVM_CAP_IRQCHIP:
> @@ -43,7 +45,7 @@ static inline bool kvm_pvm_ext_allowed(long ext)
>  	case KVM_CAP_ARM_PTRAUTH_GENERIC:
>  		return true;
>  	default:
> -		return false;
> +		return !kvm || !kvm_vm_is_protected(kvm);

I find this expression a bit unreadable. IMO it would be better if
written as:

		return !(kvm && kvm_vm_is_protected(kvm));

which makes it "clear" that you claim to support everything when
either kvm == NULL or described an unprotected VM.

But it then begs the question:

- in what circumstances is kvm == NULL? Is there any case outside of
  kvm_vm_check_extension()?

- do you really support everything?

>  	}
>  }
>  
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 870953b4a8a7..10d853f2722e 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -87,7 +87,7 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
>  	if (cap->flags)
>  		return -EINVAL;
>  
> -	if (kvm_vm_is_protected(kvm) && !kvm_pvm_ext_allowed(cap->cap))
> +	if (is_protected_kvm_enabled() && !kvm_pkvm_ext_allowed(kvm, cap->cap))
>  		return -EINVAL;
>  
>  	switch (cap->cap) {
> @@ -299,7 +299,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>  {
>  	int r;
>  
> -	if (kvm && kvm_vm_is_protected(kvm) && !kvm_pvm_ext_allowed(ext))
> +	if (is_protected_kvm_enabled() && !kvm_pkvm_ext_allowed(kvm, ext))
>  		return 0;

But that's a change in semantics here. Calling this function outside
of the context of a VM (kvm == NULL) will now report that *ALL*
extensions are valid, instead of limiting it to the allow-list.

With that, userspace can no longer detect what is available and what
isn't before creating a VM with the correct VM type.

I don't think this is the right way to do this, unless you really want
to break the existing UAPI (rhetorical question).

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2025-11-26 10:53 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-18 10:37 [PATCH v5 0/9] KVM: arm64: Fixes for guest CPU feature trapping and enabling Fuad Tabba
2025-11-18 10:37 ` [PATCH v5 1/9] KVM: arm64: Fix Trace Buffer trapping for protected VMs Fuad Tabba
2025-11-18 10:37 ` [PATCH v5 2/9] KVM: arm64: Fix Trace Buffer trap polarity " Fuad Tabba
2025-11-18 11:11   ` Suzuki K Poulose
2025-11-26 10:23   ` Marc Zyngier
2025-11-26 10:29     ` James Clark
2025-11-26 10:36       ` Fuad Tabba
2025-11-26 10:39         ` James Clark
2025-11-26 10:37     ` Fuad Tabba
2025-11-26 11:47       ` Marc Zyngier
2025-11-26 11:48         ` Fuad Tabba
2025-11-27 15:26           ` James Clark
2025-11-27 15:38             ` Fuad Tabba
2025-11-27 16:06               ` James Clark
2025-11-27 16:23                 ` Fuad Tabba
2025-11-18 10:38 ` [PATCH v5 3/9] KVM: arm64: Fix MTE flag initialization " Fuad Tabba
2025-11-18 10:38 ` [PATCH v5 4/9] KVM: arm64: Introduce helper to calculate fault IPA offset Fuad Tabba
2025-11-18 10:38 ` [PATCH v5 5/9] KVM: arm64: Include VM type when checking VM capabilities in pKVM Fuad Tabba
2025-11-26 10:52   ` Marc Zyngier [this message]
2025-11-26 11:00     ` Fuad Tabba
2025-11-26 15:36       ` Marc Zyngier
2025-11-26 17:05         ` Fuad Tabba
2025-11-18 10:38 ` [PATCH v5 6/9] KVM: arm64: Do not allow KVM_CAP_ARM_MTE for any guest " Fuad Tabba
2025-11-18 10:38 ` [PATCH v5 7/9] KVM: arm64: Track KVM IOCTLs and their associated KVM caps Fuad Tabba
2025-11-18 10:38 ` [PATCH v5 8/9] KVM: arm64: Check whether a VM IOCTL is allowed in pKVM Fuad Tabba
2025-11-18 10:38 ` [PATCH v5 9/9] KVM: arm64: Prevent host from managing timer offsets for protected VMs Fuad Tabba
2025-11-18 10:39 ` [PATCH v5 0/9] KVM: arm64: Fixes for guest CPU feature trapping and enabling Fuad Tabba

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=867bvdqd4m.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=joey.gouly@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=oliver.upton@linux.dev \
    --cc=suzuki.poulose@arm.com \
    --cc=tabba@google.com \
    --cc=vladimir.murzin@arm.com \
    --cc=will@kernel.org \
    --cc=yuzenghui@huawei.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.