linux-kernel - Re: [PATCH] ftrace: Remove possible deadlock between register_kprobe() and ftrace_run_update

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] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 29 Jun 2019 22:56:47 +0200 (CEST)
From:   Jiri Kosina <jikos@...nel.org>
To:     Steven Rostedt <rostedt@...dmis.org>
cc:     Josh Poimboeuf <jpoimboe@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Petr Mladek <pmladek@...e.com>,
        Miroslav Benes <mbenes@...e.cz>, Jessica Yu <jeyu@...nel.org>,
        Joe Lawrence <joe.lawrence@...hat.com>,
        linux-kernel@...r.kernel.org, live-patching@...r.kernel.org,
        Johannes Erdfelt <johannes@...felt.com>,
        Ingo Molnar <mingo@...nel.org>, mhiramat@...nel.org,
        torvalds@...ux-foundation.org
Subject: Re: [PATCH] ftrace: Remove possible deadlock between register_kprobe()
 and ftrace_run_update_code()

On Fri, 28 Jun 2019, Steven Rostedt wrote:

> > > > How is that supposed to work?
> > > > 
> > > >     ftrace  	     	
> > > > 	prepare()
> > > > 	 setrw()
> > > > 			setro()
> > > > 	patch <- FAIL  
> > > 
> > > /me dodges frozen shark
> > > 
> > > You are right of course.  My brain has apparently already shut off for
> > > the day.
> > > 
> > > Maybe a comment or two would help though.  
> > 
> > I'd actually prefer (perhaps in parallel to the comment) using the 
> > __acquires() and __releases() anotations, so that sparse and friends don't 
> > get confused by that either.
> > 
> 
> Care to send a patch? :-)

From: Jiri Kosina <jkosina@...e.cz>
Subject: [PATCH] ftrace/x86: anotate text_mutex split between ftrace_arch_code_modify_post_process() and ftrace_arch_code_modify_prepare()

ftrace_arch_code_modify_prepare() is acquiring text_mutex, while the 
corresponding release is happening in ftrace_arch_code_modify_post_process().

This has already been documented in the code, but let's also make the fact 
that this is intentional clear to the semantic analysis tools such as 
sparse.

Fixes: 39611265edc1a ("ftrace/x86: Add a comment to why we take text_mutex in ftrace_arch_code_modify_prepare()")
Fixes: d5b844a2cf507 ("ftrace/x86: Remove possible deadlock between register_kprobe() and ftrace_run_update_code()")
Signed-off-by: Jiri Kosina <jkosina@...e.cz>
---
 arch/x86/kernel/ftrace.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
index d7e93b2783fd..76228525acd0 100644
--- a/arch/x86/kernel/ftrace.c
+++ b/arch/x86/kernel/ftrace.c
@@ -35,6 +35,7 @@
 #ifdef CONFIG_DYNAMIC_FTRACE
 
 int ftrace_arch_code_modify_prepare(void)
+    __acquires(&text_mutex)
 {
 	/*
 	 * Need to grab text_mutex to prevent a race from module loading
@@ -48,6 +49,7 @@ int ftrace_arch_code_modify_prepare(void)
 }
 
 int ftrace_arch_code_modify_post_process(void)
+    __releases(&text_mutex)
 {
 	set_all_modules_text_ro();
 	set_kernel_text_ro();

-- 
Jiri Kosina
SUSE Labs