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 BD80C330B2A; Mon, 20 Oct 2025 17:05:06 +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=1760979906; cv=none; b=BZxK0U/vt6sXOzLvHzXewoSDY+PJENRqbAttFI9RY6yPYF9bd8bnl/xpHIEZ1vmGWePSPgySXnifgsNzTgDKphNXin3Hu1NnlC5kQVPuS3ucWZ4K534Bcs5FYEZdY+E08b8SUskVOmd7YY/Y43rZB2+qHxwWSX/i5T/g7aUj51Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760979906; c=relaxed/simple; bh=aOxVPX/stENfYbyxAxdQ2trXPVhmxu69UvS1Y1oOJF8=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=ZIwgYF7TP7s6viwK0kdsj+9gnNVCi5NDes5+i6qUcUWAm/t//+9GCrOt/7q1RG3dEiShQy8CcI9KXp7yPpEWS67ytOaOmgN5NMYD548pujUKMnrth01WXUr0M/fOtfS1EGBRhnkSsQ18ag6hGIYa5oqMQNGbAFnF87mJZT/zJLo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HlLf+uu1; 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="HlLf+uu1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 32B33C4CEF9; Mon, 20 Oct 2025 17:05:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1760979906; bh=aOxVPX/stENfYbyxAxdQ2trXPVhmxu69UvS1Y1oOJF8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=HlLf+uu1A+9glk1xokZA2dQ7TAtEcg65CYsuIrXkDFUW/3iO5kbyLa1Nz22Gz4GZH R9teEXbX5glQ3aczLPG59dylLlIyqvwnGr2WlKnCPW0Wy52t5Zc+enhyLRnakWk8+5 GC2X1llO4MAG7E+ufqUtS24JNbpQgarIL42C6yN7WHt8Kl2t/LFmta0l4wANSlgEy4 YYCV5CGmAOW2vLmZIWJVFF73VIBBdhzvBKuqYm6qtRY6aBa9tXqV5lV/fhfV3s4i9U 5nTMSxBe+XEoDcU9uyNffgYRGN3jDl5i2N2OLCAPtnLAk+U2AJDTEfxQIg20+pFv2+ J5dVj48neEruQ== 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 1vAtJf-0000000FaGq-3F9t; Mon, 20 Oct 2025 17:05:04 +0000 Date: Mon, 20 Oct 2025 18:05:03 +0100 Message-ID: <86ikg9wlkw.wl-maz@kernel.org> From: Marc Zyngier To: Ada Couprie Diaz Cc: linux-arm-kernel@lists.infradead.org, Catalin Marinas , Will Deacon , Oliver Upton , Ard Biesheuvel , Joey Gouly , Suzuki K Poulose , Zenghui Yu , Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev, kasan-dev@googlegroups.com, Mark Rutland Subject: Re: [RFC PATCH 12/16] kvm/arm64: make alternative callbacks safe In-Reply-To: <20250923174903.76283-13-ada.coupriediaz@arm.com> References: <20250923174903.76283-1-ada.coupriediaz@arm.com> <20250923174903.76283-13-ada.coupriediaz@arm.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: linux-kernel@vger.kernel.org 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 X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: ada.coupriediaz@arm.com, linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, will@kernel.org, oliver.upton@linux.dev, ardb@kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, ryabinin.a.a@gmail.com, glider@google.com, andreyknvl@gmail.com, dvyukov@google.com, vincenzo.frascino@arm.com, linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev, kasan-dev@googlegroups.com, mark.rutland@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false nit: please keep $SUBJECT in keeping with the subsystem you are patching: "KVM: arm64: Make alternative callbacks safe" On Tue, 23 Sep 2025 18:48:59 +0100, Ada Couprie Diaz wrote: > > Alternative callback functions are regular functions, which means they > or any function they call could get patched or instrumented > by alternatives or other parts of the kernel. > Given that applying alternatives does not guarantee a consistent state > while patching, only once done, and handles cache maintenance manually, > it could lead to nasty corruptions and execution of bogus code. > > Make the KVM alternative callbacks safe by marking them `noinstr` and > `__always_inline`'ing their helpers. > This is possible thanks to previous commits making `aarch64_insn_...` > functions used in the callbacks safe to inline. > > `kvm_update_va_mask()` is already marked as `__init`, which has its own > text section conflicting with the `noinstr` one. > Instead, use `__no_instr_section(".noinstr.text")` to add > all the function attributes added by `noinstr`, without the section > conflict. > This can be an issue, as kprobes seems to only block the text sections, > not based on function attributes. > > Signed-off-by: Ada Couprie Diaz > --- > This is missing `kvm_patch_vector_branch()`, which could receive the same > treatment, but the `WARN_ON_ONCE` in the early-exit check would make it > call into instrumentable code. > I do not currently know if this `WARN` can safely be removed or if it > has some importance. This is only debug code, which could be easily removed. However, I'd like to suggest that we add a method to indicate that a patching callback has failed for whatever reason. This doesn't have to be a complex piece of infrastructure, and can be best effort (you can only fail a single callback in a single location). But it would certainly help catching unexpected situations (been there, done that, ended up with visible scars...). > --- > arch/arm64/kvm/va_layout.c | 12 +++++++----- > 1 file changed, 7 insertions(+), 5 deletions(-) > > diff --git a/arch/arm64/kvm/va_layout.c b/arch/arm64/kvm/va_layout.c > index 91b22a014610..3ebb7e0074f6 100644 > --- a/arch/arm64/kvm/va_layout.c > +++ b/arch/arm64/kvm/va_layout.c > @@ -109,7 +109,7 @@ __init void kvm_apply_hyp_relocations(void) > } > } > > -static u32 compute_instruction(int n, u32 rd, u32 rn) > +static __always_inline u32 compute_instruction(int n, u32 rd, u32 rn) > { > u32 insn = AARCH64_BREAK_FAULT; > > @@ -151,6 +151,7 @@ static u32 compute_instruction(int n, u32 rd, u32 rn) > return insn; > } > > +__noinstr_section(".init.text") > void __init kvm_update_va_mask(struct alt_instr *alt, > __le32 *origptr, __le32 *updptr, int nr_inst) > { > @@ -241,7 +242,8 @@ void kvm_patch_vector_branch(struct alt_instr *alt, > *updptr++ = cpu_to_le32(insn); > } > > -static void generate_mov_q(u64 val, __le32 *origptr, __le32 *updptr, int nr_inst) > +static __always_inline void generate_mov_q(u64 val, __le32 *origptr, > + __le32 *updptr, int nr_inst) > { > u32 insn, oinsn, rd; > generate_mov_q() (and others) start with a BUG_ON(), which may not be recoverable, just like WARN_ON() above. That's where we should be able to fail (more or less) gracefully and at least indicate the failure. Thanks, M. -- Without deviation from the norm, progress is not possible.