From: Marc Zyngier <maz@kernel.org>
To: James Clark <james.clark@linaro.org>
Cc: Yingchao Deng <yingchao.deng@oss.qualcomm.com>,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-kernel@vger.kernel.org, quic_yingdeng@quicinc.com,
jinlong.mao@oss.qualcomm.com, tingwei.zhang@oss.qualcomm.com,
Oliver Upton <oliver.upton@linux.dev>,
Joey Gouly <joey.gouly@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>
Subject: Re: [PATCH] KVM: arm64: Fix NULL pointer access issue
Date: Mon, 01 Sep 2025 14:30:35 +0100 [thread overview]
Message-ID: <86y0qycnb8.wl-maz@kernel.org> (raw)
In-Reply-To: <80178c90-b9f3-4e1f-baa5-f54aa89ec927@linaro.org>
On Mon, 01 Sep 2025 13:31:23 +0100,
James Clark <james.clark@linaro.org> wrote:
>
>
>
> On 01/09/2025 1:24 pm, Marc Zyngier wrote:
> > On Mon, 01 Sep 2025 11:36:11 +0100,
> > James Clark <james.clark@linaro.org> wrote:
> >>
> >>
> >>
> >> On 01/09/2025 11:01 am, Yingchao Deng wrote:
> >>> When linux is booted in EL1, macro "host_data_ptr()" is a wrapper that
> >>> resolves to "&per_cpu_ptr_nvhe_sym(kvm_host_data, cpu)",
> >>> is_hyp_mode_available() return false during kvm_arm_init, the per-CPU base
> >>> pointer __kvm_nvhe_kvm_arm_hyp_percpu_base[cpu] remains uninitialized.
> >>> Consequently, any access via per_cpu_ptr_nvhe_sym(kvm_host_data, cpu)
> >>> will result in a NULL pointer.
> >>>
> >>> Add is_kvm_arm_initialised() condition check to ensure that kvm_arm_init
> >>> completes all necessary initialization steps, including init_hyp_mode.
> >>>
> >>> Fixes: 054b88391bbe2 ("KVM: arm64: Support trace filtering for guests")
> >>> Signed-off-by: Yingchao Deng <yingchao.deng@oss.qualcomm.com>
> >>> ---
> >>> Add a check to prevent accessing uninitialized per-CPU data.
> >>> ---
> >>> arch/arm64/kvm/debug.c | 7 ++++---
> >>> 1 file changed, 4 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
> >>> index 381382c19fe4741980c79b08bbdab6a1bcd825ad..add58056297293b4eb337028773b1b018ecc9d35 100644
> >>> --- a/arch/arm64/kvm/debug.c
> >>> +++ b/arch/arm64/kvm/debug.c
> >>> @@ -233,7 +233,7 @@ void kvm_debug_handle_oslar(struct kvm_vcpu *vcpu, u64 val)
> >>> void kvm_enable_trbe(void)
> >>> {
> >>> if (has_vhe() || is_protected_kvm_enabled() ||
> >>> - WARN_ON_ONCE(preemptible()))
> >>> + WARN_ON_ONCE(preemptible()) || !is_kvm_arm_initialised())
> >>
> >> Hi Yingchao,
> >>
> >> There shouldn't be a warning for this, at least for the case where
> >> it's not initialized and never will be. If you're never going to run a
> >> guest these functions can all skip, the same way for !has_vhe() etc.
> >
> > It's not a warning. It's a bona-fide crash:
> >
> > void kvm_enable_trbe(void)
> > {
> > if (has_vhe() || is_protected_kvm_enabled() ||
> > WARN_ON_ONCE(preemptible()))
> > return;
> >
> > host_data_set_flag(TRBE_ENABLED); <--- Explodes here
> > }
> >
> > So the write of the flag has to be skipped if KVM is available, even
> > if KVM is compiled in.
> >
> > M.
> >
>
> Yeah. And just in case there is any confusion, I didn't mean that we
> should not have the check entirely, just that it shouldn't be in the
> WARN_ON_ONCE(). We should put it in the part that makes the functions
> silently skip:
>
> if (has_vhe() || is_protected_kvm_enabled() ||
> !is_kvm_arm_initialised() ||
> WARN_ON_ONCE(preemptible()))
> return;
Which is exactly what the OP wrote, except for swapping the last two
terms.
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2025-09-01 13:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-01 10:01 [PATCH] KVM: arm64: Fix NULL pointer access issue Yingchao Deng
2025-09-01 10:36 ` James Clark
2025-09-01 12:24 ` Marc Zyngier
2025-09-01 12:31 ` James Clark
2025-09-01 13:30 ` Marc Zyngier [this message]
2025-09-01 14:16 ` James Clark
2025-09-02 3:30 ` Yingchao Deng (Consultant)
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=86y0qycnb8.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=james.clark@linaro.org \
--cc=jinlong.mao@oss.qualcomm.com \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oliver.upton@linux.dev \
--cc=quic_yingdeng@quicinc.com \
--cc=suzuki.poulose@arm.com \
--cc=tingwei.zhang@oss.qualcomm.com \
--cc=will@kernel.org \
--cc=yingchao.deng@oss.qualcomm.com \
--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.