linux-kernel - Re: Question about ftrace, dynamically allocated trampolines and dynamic fops

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:	Thu, 29 Jan 2015 09:41:32 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Miroslav Benes <mbenes@...e.cz>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	jkosina@...e.cz
Subject: Re: Question about ftrace, dynamically allocated trampolines and
 dynamic fops

On Thu, 29 Jan 2015 10:40:58 +0100 (CET)
Miroslav Benes <mbenes@...e.cz> wrote:

> 
> Hi,
> 
> solving a possible race condition in kGraft and thinking about the same in 
> klp live patching I looked quite a lot at ftrace code. One thing about 
> recent dynamic trampolines seems a bit odd. For dynamic fops 
> (FTRACE_OPS_FL_DYNAMIC is set in ops->flags) arch_ftrace_update_trampoline 
> is called only for nonpreemptive kernels in ftrace_update_trampoline. The 
> reason is obvious and well described in the comment there. However the 
> actual callback function in arch_ftrace_update_trampoline is 
> determined by call to ftrace_ops_get_func which gives generic 
> ftrace_ops_list_func for dynamic ops. This function disables preemption 
> (because of traversing rcu protected list), so it should be safe to use 
> dynamic trampolines even for dynamic fops in preemptive kernels. Is this 
> correct? 

No, the dynamic trampoline itself is not safe. I explained this at the
LinuxConEU/Plumbers conference, although the slides don't explain it
well :-/, otherwise I would have just pointed you to them.

Basically what the issue is, if a task jumps to the dynamic trampoline
and gets preempted, how would you ever free that trampoline again?

Now for live kernel patching, we could add another flag that says
permanent, that means the trampoline and the ops will never be free or
change, and then it would be safe to use dynamic trampolines.

> 
> Or maybe the problem is the opposite. Why does the ftrace use 
> ftrace_ops_list_func in such situation? Even for nonpreemptive kernel and 
> dynamic fops ftrace_ops_list_func has unnecessary overhead.

It points the dynamic ops (in non-preempt) to ftrace_ops_list_func? Are
you sure about that. One way to verify is to
cat /sys/kernel/debug/tracing/enabled_functions, which should show you
want the dynamic ops points to.

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/