linux-kernel - Re: [PATCH v3 8/8] x86/ftrace: enable EXECMEM_ROX

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aKa4otIF6AbhD2X3@kernel.org>
Date: Thu, 21 Aug 2025 09:11:46 +0300
From: Mike Rapoport <rppt@...nel.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
	Andy Lutomirski <luto@...nel.org>, Borislav Petkov <bp@...en8.de>,
	Christophe Leroy <christophe.leroy@...roup.eu>,
	Daniel Gomez <da.gomez@...sung.com>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	Ingo Molnar <mingo@...hat.com>,
	"Liam R. Howlett" <Liam.Howlett@...cle.com>,
	Luis Chamberlain <mcgrof@...nel.org>,
	Mark Rutland <mark.rutland@....com>,
	Masami Hiramatsu <mhiramat@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Petr Pavlu <petr.pavlu@...e.com>,
	Sami Tolvanen <samitolvanen@...gle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Yann Ylavic <ylavic.dev@...il.com>, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, linux-modules@...r.kernel.org,
	linux-trace-kernel@...r.kernel.org, x86@...nel.org
Subject: Re: [PATCH v3 8/8] x86/ftrace: enable EXECMEM_ROX_CACHE for ftrace
 allocations

On Wed, Aug 20, 2025 at 06:47:43PM -0400, Steven Rostedt wrote:
> On Sun, 13 Jul 2025 10:17:30 +0300
> Mike Rapoport <rppt@...nel.org> wrote:
> 
> > From: "Mike Rapoport (Microsoft)" <rppt@...nel.org>
> > 
> > For the most part ftrace uses text poking and can handle ROX memory.
> > The only place that requires writable memory is create_trampoline() that
> > updates the allocated memory and in the end makes it ROX.
> > 
> > Use execmem_alloc_rw() in x86::ftrace::alloc_tramp() and enable ROX cache
> > for EXECMEM_FTRACE when configuration and CPU features allow that.
> > 
> > Acked-by: Peter Zijlstra (Intel) <peterz@...radead.org>
> > Signed-off-by: Mike Rapoport (Microsoft) <rppt@...nel.org>
> > ---
> 
> The "ftrace=function" kernel command line started crashing with v6.17-rc1,
> and I bisected it down to this commit:
> 
>  5d79c2be5081 ("x86/ftrace: enable EXECMEM_ROX_CACHE for ftrace allocations")
> 
> On boot I hit this:
> 
> [    0.159269] BUG: kernel NULL pointer dereference, address: 000000000000001c
> [    0.160254] #PF: supervisor read access in kernel mode
> [    0.160975] #PF: error_code(0x0000) - not-present page
> [    0.161697] PGD 0 P4D 0
> [    0.162055] Oops: Oops: 0000 [#1] SMP PTI
> [    0.162619] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.17.0-rc2-test-00006-g48d06e78b7cb-dirty #9 PREEMPT(undef)
> [    0.164141] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
> [    0.165439] RIP: 0010:kmem_cache_alloc_noprof (mm/slub.c:4237) 
> [    0.177483] Call Trace:
> [    0.177828]  <TASK>
> [    0.178123] mas_alloc_nodes (lib/maple_tree.c:176 (discriminator 2) lib/maple_tree.c:1255 (discriminator 2)) 
> [    0.178692] mas_store_gfp (lib/maple_tree.c:5468) 
> [    0.179223] execmem_cache_add_locked (mm/execmem.c:207) 
> [    0.179870] execmem_alloc (mm/execmem.c:213 mm/execmem.c:313 mm/execmem.c:335 mm/execmem.c:475) 
> [    0.180397] ? ftrace_caller (arch/x86/kernel/ftrace_64.S:169) 
> [    0.180922] ? __pfx_ftrace_caller (arch/x86/kernel/ftrace_64.S:158) 
> [    0.181517] execmem_alloc_rw (mm/execmem.c:487) 
> [    0.182052] arch_ftrace_update_trampoline (arch/x86/kernel/ftrace.c:266 arch/x86/kernel/ftrace.c:344 arch/x86/kernel/ftrace.c:474) 
> [    0.182778] ? ftrace_caller_op_ptr (arch/x86/kernel/ftrace_64.S:182) 
> [    0.183388] ftrace_update_trampoline (kernel/trace/ftrace.c:7947) 
> [    0.184024] __register_ftrace_function (kernel/trace/ftrace.c:368) 
> [    0.184682] ftrace_startup (kernel/trace/ftrace.c:3048) 
> [    0.185205] ? __pfx_function_trace_call (kernel/trace/trace_functions.c:210) 
> [    0.185877] register_ftrace_function_nolock (kernel/trace/ftrace.c:8717) 
> [    0.186595] register_ftrace_function (kernel/trace/ftrace.c:8745) 
> [    0.187254] ? __pfx_function_trace_call (kernel/trace/trace_functions.c:210) 
> [    0.187924] function_trace_init (kernel/trace/trace_functions.c:170) 
> [    0.188499] tracing_set_tracer (kernel/trace/trace.c:5916 kernel/trace/trace.c:6349) 
> [    0.189088] register_tracer (kernel/trace/trace.c:2391) 
> [    0.189642] early_trace_init (kernel/trace/trace.c:11075 kernel/trace/trace.c:11149) 
> [    0.190204] start_kernel (init/main.c:970) 
> [    0.190732] x86_64_start_reservations (arch/x86/kernel/head64.c:307) 
> [    0.191381] x86_64_start_kernel (??:?) 
> [    0.191955] common_startup_64 (arch/x86/kernel/head_64.S:419) 
> [    0.192534]  </TASK>
> [    0.192839] Modules linked in:
> [    0.193267] CR2: 000000000000001c
> [    0.193730] ---[ end trace 0000000000000000 ]---

maple tree is initialized after ftrace, so the patch below should fix it:

diff --git a/init/main.c b/init/main.c
index 0ee0ee7b7c2c..5753e9539ae6 100644
--- a/init/main.c
+++ b/init/main.c
@@ -956,6 +956,7 @@ void start_kernel(void)
 	sort_main_extable();
 	trap_init();
 	mm_core_init();
+	maple_tree_init();
 	poking_init();
 	ftrace_init();
 
@@ -973,7 +974,6 @@ void start_kernel(void)
 		 "Interrupts were enabled *very* early, fixing it\n"))
 		local_irq_disable();
 	radix_tree_init();
-	maple_tree_init();
 
 	/*
 	 * Set up housekeeping before setting up workqueues to allow the unbound
 
> -- Steve

-- 
Sincerely yours,
Mike.