All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Vincent Donnefort" <vdonnefort@google.com>
Cc: "Marc Zyngier" <maz@kernel.org>,
	kvmarm@lists.linux.dev, "Oliver Upton" <oupton@kernel.org>
Subject: Re: [PATCH v3 09/17] KVM: arm64: Add selftests for the pKVM heap allocator
Date: Mon, 20 Jul 2026 17:31:12 +0000	[thread overview]
Message-ID: <20260720173112.EA9101F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260720171513.1415357-10-vdonnefort@google.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The `__KVM_HOST_SMCCC_FUNC___pkvm_hyp_alloc_selftest` hypercall is incorrectly placed in the always-on band rather than the init-only band.
- [Medium] Physical pages are permanently leaked in the hypervisor if the allocator selftest encounters an error.
--

--- Patch [9]: [PATCH v3 09/17] KVM: arm64: Add selftests for the pKVM heap allocator ---
commit db8b74b081ab779ef5c70d80095da5b5809ca9d3
Author: Vincent Donnefort <vdonnefort@google.com>

KVM: arm64: Add selftests for the pKVM heap allocator

Introduce a comprehensive runtime selftest for the pKVM hypervisor heap
allocator, executed during init when CONFIG_NVHE_EL2_DEBUG is enabled.

> diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
> index 0c3126179704f..08466f608d1f5 100644
> --- a/arch/arm64/include/asm/kvm_asm.h
> +++ b/arch/arm64/include/asm/kvm_asm.h
> @@ -92,6 +92,7 @@ enum __kvm_host_smccc_func {
>  	__KVM_HOST_SMCCC_FUNC___pkvm_hyp_topup,
>  	__KVM_HOST_SMCCC_FUNC___pkvm_hyp_reclaim,
>  	__KVM_HOST_SMCCC_FUNC___pkvm_hyp_reclaimable,
> +	__KVM_HOST_SMCCC_FUNC___pkvm_hyp_alloc_selftest,
>  
>  	MARKER(__KVM_HOST_SMCCC_FUNC_PKVM_ONLY),

[Severity: Medium]
Does this place the initialization-only test hypercall in the always-on band?

If __pkvm_hyp_alloc_selftest is only intended to run during initialization,
placing it here (before PKVM_ONLY) exposes it to the untrusted host
post-deprivilege. This allows the host to drive synchronous EL2 execution at
runtime. Should it be placed in the init-only band instead?

[ ... ]

> diff --git a/arch/arm64/kvm/hyp/nvhe/alloc.c b/arch/arm64/kvm/hyp/nvhe/alloc.c
> index 32c923d83f78b..49d7560ad150e 100644
> --- a/arch/arm64/kvm/hyp/nvhe/alloc.c
> +++ b/arch/arm64/kvm/hyp/nvhe/alloc.c

[ ... ]

> +	/* Test reclaiming the last chunk of the list */
> +	selftest_free(addr4);
> +	hyp_allocator_reclaim(allocator, &host_mc, SELFTEST_MAX_PAGES);
> +	if (host_mc.nr_pages != SELFTEST_MAX_PAGES - 3)
> +		return -EINVAL;
> +
> +	/* Test punching a hole in the middle of a free chunk ... */
> +	selftest_free(addr2);
> +	hyp_allocator_reclaim(allocator, &host_mc, SELFTEST_MAX_PAGES);
> +	if (host_mc.nr_pages != SELFTEST_MAX_PAGES - 2)
> +		return -EINVAL;
> +
> +	if (selftest_alloc(PAGE_SIZE))
> +		return -EINVAL;
> +	if (selftest_errno() != -ENOMEM)
> +		return -EINVAL;

[Severity: Medium]
Are these early return paths in hyp_allocator_selftest() leaking the physical
pages accumulated in the local host_mc variable?

If an error is encountered during the selftest and the function returns
early, host_mc goes out of scope. Because the physical pages populated
during the previous hyp_allocator_reclaim() calls are not returned to the
host or freed, they appear to be permanently leaked in EL2.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720171513.1415357-1-vdonnefort@google.com?part=9

  reply	other threads:[~2026-07-20 17:31 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-20 17:14 [PATCH v3 00/17] KVM: arm64: Introduce pKVM hypervisor heap allocator Vincent Donnefort
2026-07-20 17:14 ` [PATCH v3 01/17] KVM: arm64: Add pkvm_private_va_range_pa Vincent Donnefort
2026-07-20 17:25   ` sashiko-bot
2026-07-20 17:14 ` [PATCH v3 02/17] KVM: arm64: Add pkvm_remove_mappings Vincent Donnefort
2026-07-20 17:27   ` sashiko-bot
2026-07-20 17:14 ` [PATCH v3 03/17] KVM: arm64: Add pkvm_map_private_va_range Vincent Donnefort
2026-07-20 17:29   ` sashiko-bot
2026-07-20 17:15 ` [PATCH v3 04/17] KVM: arm64: Add a heap allocator for the pKVM hyp Vincent Donnefort
2026-07-20 17:26   ` sashiko-bot
2026-07-20 17:15 ` [PATCH v3 05/17] KVM: arm64: Allow kvm_hyp_memcache usage outside of stage-2 Vincent Donnefort
2026-07-20 17:15 ` [PATCH v3 06/17] KVM: arm64: Add pkvm_hyp_req infrastructure Vincent Donnefort
2026-07-20 17:15 ` [PATCH v3 07/17] KVM: arm64: Add PKVM_HYP_REQ_HYP_ALLOC request Vincent Donnefort
2026-07-20 17:36   ` sashiko-bot
2026-07-20 17:15 ` [PATCH v3 08/17] KVM: arm64: Add reclaim interface for the pKVM heap alloc Vincent Donnefort
2026-07-20 17:32   ` sashiko-bot
2026-07-20 17:15 ` [PATCH v3 09/17] KVM: arm64: Add selftests for the pKVM heap allocator Vincent Donnefort
2026-07-20 17:31   ` sashiko-bot [this message]
2026-07-20 17:15 ` [PATCH v3 10/17] KVM: arm64: Add a shrinker for pKVM Vincent Donnefort
2026-07-20 17:15 ` [PATCH v3 11/17] KVM: arm64: Filter out non-kernel addresses in kern_hyp_va Vincent Donnefort
2026-07-20 17:28   ` sashiko-bot
2026-07-20 17:15 ` [PATCH v3 12/17] KVM: arm64: Move hyp_vm refcount into the structure Vincent Donnefort
2026-07-20 17:15 ` [PATCH v3 13/17] KVM: arm64: Alloc pkvm_hyp_vm using pKVM heap allocator Vincent Donnefort
2026-07-20 17:44   ` sashiko-bot
2026-07-20 17:15 ` [PATCH v3 14/17] KVM: arm64: Alloc pkvm_hyp_vcpu " Vincent Donnefort
2026-07-20 17:41   ` sashiko-bot
2026-07-20 17:15 ` [PATCH v3 15/17] KVM: arm64: Reject hyp trace descriptors with fewer CPUs than hyp_nr_cpus Vincent Donnefort
2026-07-20 17:15 ` [PATCH v3 16/17] KVM: arm64: Reject hyp trace descriptors with fewer than 3 pages Vincent Donnefort
2026-07-20 17:15 ` [PATCH v3 17/17] KVM: arm64: Alloc simple_buffer_page using pKVM hyp allocator Vincent Donnefort
2026-07-20 17:47   ` sashiko-bot

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=20260720173112.EA9101F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=maz@kernel.org \
    --cc=oupton@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vdonnefort@google.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.