From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6E10ACCD199 for ; Mon, 20 Oct 2025 17:05:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=5Mda8oOOpYCD565rSyu3DIf2XuqcwsaLNOoOyBWIStU=; b=osqeo+F8XF9vvuLkwostneNI6w I5QBBEOx6Pmbrt8Hdi9oky5MBQcdcsz97wEkVcNknVJffPPMoJ185nJZqvrgeAoUIfooQg5JHjAIi r+nMF5mpqxv0lFJlnu/l/cZp7BfYierouAKGRnCAFbV6LsiBCkST2voe4MbfIVSJ4jvceoFbZBceC +/WHvhNgGYjSCbmNjcr1C1Zk3JCue6lja0nZIiVknAqv2hvMae5RCJrU5sckJxibbQKrMx90toSvM APQTVl3m4CfiWt3eTW7NH8iDfhBPgfbstM885CkDv3XAWSSARPB9FEnHaos//dtlwTY2Kilr2feEl Sv+4Sx1A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vAtJn-0000000EPgo-1O6y; Mon, 20 Oct 2025 17:05:11 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vAtJk-0000000EPfq-0b3n for linux-arm-kernel@lists.infradead.org; Mon, 20 Oct 2025 17:05:09 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 5859F486E0; Mon, 20 Oct 2025 17:05:06 +0000 (UTC) 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) 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20251020_100508_222556_C329657A X-CRM114-Status: GOOD ( 30.85 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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.