From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B66B32D2488; Mon, 15 Sep 2025 10:41:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757932899; cv=none; b=RIOXXqV6YDnKLcNFuaEhp2YmRpCNVhHiQdpQQ36/wJz/mWhCGARo3yiSxwG9SFA0VNPiIdLTVqQ1ifXxfQ+BROJ9ZwMhlh2uaEkjEPJ4Y9hxyc7ibZrmekbas03zVuFWYbHE2tIzdUFaismiXI64rl0P9sigpectdd6Bhmfe8HA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757932899; c=relaxed/simple; bh=Fb8y6re6cSdb3s8Dmb8ibHc12xk4vLOBlLPifU1XVpA=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=ass6clpCNIdjkOqjmFiW18QfUjRNpzzIAzz5+6DwtIxwMR6tzADkvxvm4Y4FOZn9y+WaZjkiR9Irs64nvnf+e4Bzn2UdbeIsm6xDr+sgOW4Y4v3aOrtK52bm/df9YJ06JWPVFYUEPFRcjSENLN/oWJU7ndd6uNRsjV295vu6coM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=eWELfBvj; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="eWELfBvj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 32734C4CEF1; Mon, 15 Sep 2025 10:41:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1757932899; bh=Fb8y6re6cSdb3s8Dmb8ibHc12xk4vLOBlLPifU1XVpA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=eWELfBvj6lLhW8104ktom4jIKkcNcyV2iIMdqlUhHMP4Igz2u1dYAD+kSd7vcrIGU Huv0cyYQdI8UcvX+bmSv8E2wYVbIundxUMim1rsYtlo+YA0d9KpFdZu16o7QQHL+8N p5LR6n5FdA1eRL1SXHgeSMrKXB6i7WTEAwXdbyiJIcHIvVMv/qSajV44GgbG1ZAuDR daYwylP+IMJyTRb3xnEnTRB99G5Us3p0vpApYVYD3+bJsASb2Y+zNUbxRBLUrbd9rP JVkeofqV7zqauIeTojFLSdCOio5X0mGBKIHT10rGyIIEHEgRF6zwJ5LsFrl4OyzfZs TNoMNx/4s3Qaw== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1uy6eP-00000006KhX-0F6P; Mon, 15 Sep 2025 10:41:37 +0000 Date: Mon, 15 Sep 2025 11:41:36 +0100 Message-ID: <86y0qgatgf.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Cc: Yingchao Deng , Joey Gouly , Suzuki K Poulose , Zenghui Yu , Catalin Marinas , Will Deacon , James Clark , 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 Subject: Re: [PATCH v2] KVM: arm64: Fix NULL pointer access issue In-Reply-To: References: <20250902-etm_crash-v2-1-aa9713a7306b@oss.qualcomm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: oliver.upton@linux.dev, yingchao.deng@oss.qualcomm.com, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, james.clark@linaro.org, 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 X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Thu, 04 Sep 2025 08:26:15 +0100, Oliver Upton wrote: >=20 > Hi Yingchao, >=20 > The shortlog is extremely vague, you should aim to succinctly describe > the functional change of your patch. e.g. >=20 > KVM: arm64: Return early from trace helpers when KVM isn't available >=20 > On Tue, Sep 02, 2025 at 11:48:25AM +0800, 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 b= ase > > 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. > >=20 > > Add is_kvm_arm_initialised() condition check to ensure that kvm_arm_init > > completes all necessary initialization steps, including init_hyp_mode. >=20 > OTOH, the changelog is very mechanical and hard to grok. >=20 > When linux is booted at EL1, host_data_ptr() resolves to the nVHE > hypervisor's copy of host data. When hyp mode isn't available for > KVM the nVHE percpu bases remain uninitialized. Consequently, any usage > of host_data_ptr() will result in a NULL dereference which has been > observed in KVM's trace filtering helpers. >=20 > Add an early return to the trace filtering helpers if KVM isn't > initialized, avoiding the NULL dereference. >=20 > > Fixes: 054b88391bbe2 ("KVM: arm64: Support trace filtering for guests") > > Signed-off-by: Yingchao Deng > > Reviewed-by: James Clark > > --- > > Add a check to prevent accessing uninitialized per-CPU data. > > --- > > Changes in v2: > > 1. Move the warning to the end in order to improve readability. No > > functional change intended >=20 > IMO, the warning should be the very first condition we evaluate. Even if > the system configuration leads to an early return anyway (e.g. protected > mode) the caller is not invoking these helpers from the right context. This is what I intend to merge, with the commit log repainted as above, and the helpers refactored in a slightly less ugly way (well, at least more to my own taste, YMMV). M. =46rom 27d2b47eef033f1fc6c0452dc1017e43dad5fe14 Mon Sep 17 00:00:00 2001 From: Yingchao Deng Date: Tue, 2 Sep 2025 11:48:25 +0800 Subject: [PATCH] KVM: arm64: Return early from trace helpers when KVM isn't available When Linux is booted at EL1, host_data_ptr() resolves to the nVHE hypervisor's copy of host data. When hyp mode isn't available for KVM the nVHE percpu bases remain uninitialized. Consequently, any usage of host_data_ptr() will result in a NULL dereference which has been observed in KVM's trace filtering helpers. Add an early return to the trace filtering helpers if KVM isn't initialized, avoiding the NULL dereference. Take this opportunity to move the TRBE-skipping checks to a common helper. Fixes: 054b88391bbe2 ("KVM: arm64: Support trace filtering for guests") Signed-off-by: Yingchao Deng Reviewed-by: James Clark [maz: repainted the helpers to be readable, and the commit message with Oliver's suggestion] Signed-off-by: Marc Zyngier --- arch/arm64/kvm/debug.c | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c index 381382c19fe47..1aaeb40a9a388 100644 --- a/arch/arm64/kvm/debug.c +++ b/arch/arm64/kvm/debug.c @@ -230,29 +230,29 @@ void kvm_debug_handle_oslar(struct kvm_vcpu *vcpu, u6= 4 val) preempt_enable(); } =20 -void kvm_enable_trbe(void) +static bool skip_trbe_access(bool skip_condition) { - if (has_vhe() || is_protected_kvm_enabled() || - WARN_ON_ONCE(preemptible())) - return; + return (WARN_ON_ONCE(preemptible()) || skip_condition || + is_protected_kvm_enabled() || !is_kvm_arm_initialised()); +} =20 - host_data_set_flag(TRBE_ENABLED); +void kvm_enable_trbe(void) +{ + if (!skip_trbe_access(has_vhe())) + host_data_set_flag(TRBE_ENABLED); } EXPORT_SYMBOL_GPL(kvm_enable_trbe); =20 void kvm_disable_trbe(void) { - if (has_vhe() || is_protected_kvm_enabled() || - WARN_ON_ONCE(preemptible())) - return; - - host_data_clear_flag(TRBE_ENABLED); + if (!skip_trbe_access(has_vhe())) + host_data_clear_flag(TRBE_ENABLED); } EXPORT_SYMBOL_GPL(kvm_disable_trbe); =20 void kvm_tracing_set_el1_configuration(u64 trfcr_while_in_guest) { - if (is_protected_kvm_enabled() || WARN_ON_ONCE(preemptible())) + if (skip_trbe_access(false)) return; =20 if (has_vhe()) { --=20 2.39.2 --=20 Without deviation from the norm, progress is not possible.