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

Date:	Thu, 29 Jan 2015 10:40:58 +0100 (CET)
From:	Miroslav Benes <mbenes@...e.cz>
To:	rostedt@...dmis.org
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	jkosina@...e.cz
Subject: Question about ftrace, dynamically allocated trampolines and dynamic
 fops

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? 

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.

I'm almost sure I must have missed something but I cannot see what. Could 
you point me at the right direction?

Thanks a lot in advance,
--
Miroslav Benes
SUSE Labs
--
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/