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 85DA12C859; Thu, 7 May 2026 01:46:05 +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=1778118365; cv=none; b=ISc3W9Zn8T1yDZGcec9Es1AHo6Qb/tXhPPvnHZnGOLxx2unbYm/6nHpUsuhAGK3AjZH8pwBJ4inkclnhdblljv9n/YtU/W2iwmvslyX3N8ZvK4+KTo4j3Mu8BxYQLxNnVEqaatl4dBkuK9eX9UttW2fONzQcE1Mk8NSRVWaOOwg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778118365; c=relaxed/simple; bh=SqzLSvkIU3gi/PO8FHJqLB6TXM33GjmfxL89pw1w7cU=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=EV8xEs4I4Sm7hVw6TXJFnEPSBk7JUd47/xf4TfNMnlxXpxKaZnJ92FXU6jLeXAzIlduMhFKMeyBZSkb3piietCXQy1Vq5nAQT2DWa4h8Atg7mTN8jNyV/ZedL/6awE5Rqa6Wqgjpp06Kr+BJV1f6b7AJdPe029wscB6md7bRHfk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qPpq/30u; 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="qPpq/30u" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AC16CC2BCB0; Thu, 7 May 2026 01:46:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778118365; bh=SqzLSvkIU3gi/PO8FHJqLB6TXM33GjmfxL89pw1w7cU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=qPpq/30ub8OnpZ6t9nU1XKd5OEgcXka8AoNbsyd7CIF/wCoIpl+E6IAlERzvza0yy 2JI+BeKQ07iGHjGrTw21ggAsi4OoXn9XZRYeQUdJ3Ri1pVUoPmEDVlslamyXXSa1ys /HcrZxbiyVVljOc7zbG0A2B1K6N/lr9pxQbEMP/lBKgoIoVMCoJ1zMkAcqdNzBMVsM Gx6TY8cNvR1E6WZ4mqDdprtAIyHMWrgAqL8Pt1KW0tQtKhBTJLCBWXhNcHAIC0Kqck 9V6ITPp0sSA6QBLZfsy7Y6P0DKVa6eBsMePrpApvETjxfQtNa6fqg1IE2m7/jfnEiU VYetI6gI9TMQw== Date: Thu, 7 May 2026 10:46:02 +0900 From: Masami Hiramatsu (Google) To: Jianpeng Chang Cc: , , , , , , , , Subject: Re: [v2 PATCH] kprobes: skip non-symbol addresses in kprobe_add_ksym_blacklist() Message-Id: <20260507104602.b5dc0e1d6369b22e65b61d1c@kernel.org> In-Reply-To: <20260506012706.2785785-1-jianpeng.chang.cn@windriver.com> References: <20260506012706.2785785-1-jianpeng.chang.cn@windriver.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-trace-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 6 May 2026 09:27:06 +0800 Jianpeng Chang wrote: > When kprobe_add_area_blacklist() iterates through a section like > .kprobes.text, the start address may not correspond to a named symbol. > On ARM64 with CONFIG_DYNAMIC_FTRACE_WITH_CALL_OPS=y (introduced by > commit baaf553d3bc3 ("arm64: Implement > HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS")), the compiler flag > -fpatchable-function-entry=4,2 inserts 2 NOPs before each function entry > point for ftrace call_ops. These pre-function NOPs sit at the section base > address, before the first named function symbol. The compiler emits a $x > mapping symbol at offset 0x00 to mark the start of code, but > find_kallsyms_symbol() ignores mapping symbols. > > Without CONFIG_DYNAMIC_FTRACE_WITH_CALL_OPS (e.g. defconfig), no > pre-function NOPs are inserted, the first function starts at offset > 0x00, and the bug does not trigger. > > This only affects modules that have a .kprobes.text section (i.e. those > using the __kprobes annotation). Modules using NOKPROBE_SYMBOL() instead > (like kretprobe_example.ko) blacklist exact function addresses via the > _kprobe_blacklist section and are not affected. > > For kprobe_example.ko on ARM64 with -fpatchable-function-entry=4,2, > the .kprobes.text section layout is: > > offset 0x00: $x + 2 NOPs (mapping symbol + ftrace preamble) > offset 0x08: handler_post (64 bytes) > offset 0x50: handler_pre (68 bytes) > > kprobe_add_area_blacklist() starts iterating from the section base > address (offset 0x00), which only has the $x mapping symbol. > kprobe_add_ksym_blacklist() then calls kallsyms_lookup_size_offset() > for this address, which goes through: > > kallsyms_lookup_size_offset() > -> module_address_lookup() > -> find_kallsyms_symbol() > > find_kallsyms_symbol() scans all module symbols to find the closest > preceding symbol. > > Since no named text symbol exists at offset 0x00, > find_kallsyms_symbol() picks __UNIQUE_ID_vermagic (a .modinfo symbol > whose address is in the temporary image) as the "best" match. The > computed "size" = next_text_symbol - modinfo_symbol spans across > these two unrelated memory regions, creating a blacklist entry with > a bogus range of tens of terabytes. > > Whether this causes a visible failure depends on address randomization, > here is what happens on Raspberry Pi 4/5: > > - On RPi5, the bogus size was ~35 TB. start + size stayed within > 64-bit range, so the blacklist entry covered the entire kernel > text. register_kprobe() in the module's own init function failed > with -EINVAL. > > - On RPi4, the bogus size was ~75 TB. start + size overflowed > 64 bits and wrapped to a small address near zero. The range > check (addr >= start && addr < end) then failed because end > wrapped around, so the bogus entry was accidentally harmless > and kprobes worked by luck. > > The same bug exists on both machines, but randomization determines whether > the integer overflow masks it or not. > > Fix this by adding notrace to the __kprobes macro. Functions in > .kprobes.text are kprobe infrastructure handlers that should never be > traced by ftrace. With notrace, the compiler stops inserting them and the > non-symbol gap at the section start disappears entirely. > Thanks, this looks good to me! > Fixes: baaf553d3bc3 ("arm64: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS") > Signed-off-by: Jianpeng Chang > --- > v2: > - use notrace instead of skipping the nops > v1: https://lore.kernel.org/all/20260427073545.3656835-1-jianpeng.chang.cn@windriver.com/ > > include/asm-generic/kprobes.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/asm-generic/kprobes.h b/include/asm-generic/kprobes.h > index 060eab094e5a..5290a2b2e15a 100644 > --- a/include/asm-generic/kprobes.h > +++ b/include/asm-generic/kprobes.h > @@ -14,7 +14,7 @@ static unsigned long __used \ > _kbl_addr_##fname = (unsigned long)fname; > # define NOKPROBE_SYMBOL(fname) __NOKPROBE_SYMBOL(fname) > /* Use this to forbid a kprobes attach on very low level functions */ > -# define __kprobes __section(".kprobes.text") > +# define __kprobes notrace __section(".kprobes.text") > # define nokprobe_inline __always_inline > #else > # define NOKPROBE_SYMBOL(fname) > -- > 2.54.0 > -- Masami Hiramatsu (Google)