linux-kernel - Re: [PATCH] ftrace: fix race between ftrace and insmod

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]

Message-ID: <566F8871.7070408@linux.intel.com>
Date:	Tue, 15 Dec 2015 11:26:41 +0800
From:	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>
To:	Steven Rostedt <rostedt@...dmis.org>,
	"Qiu, PeiyangX" <peiyangx.qiu@...el.com>
CC:	linux-kernel@...r.kernel.org, mingo@...hat.com,
	Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: [PATCH] ftrace: fix race between ftrace and insmod

On 2015/12/15 9:05, Zhang, Yanmin wrote:
> On 2015/12/14 23:51, Steven Rostedt wrote:
>> On Mon, 14 Dec 2015 11:16:18 +0800
>> "Qiu, PeiyangX" <peiyangx.qiu@...el.com> wrote:
>>
>>> We hit ftrace_bug report when booting Android on a 64bit ATOM SOC chip.
>>> Basically, there is a race between insmod and ftrace_run_update_code.
>>>
>>> After load_module=>ftrace_module_init, another thread jumps in to call
>>> ftrace_run_update_code=>ftrace_arch_code_modify_prepare
>>>                          =>set_all_modules_text_rw, to change all modules  
>>> as RW. Since the new module is at MODULE_STATE_UNFORMED, the text attribute
>>> is not changed. Then, the 2nd thread goes ahead to change codes.
>>> However, load_module continues to call 
>>> complete_formation=>set_section_ro_nx,  
>>> then 2nd thread would fail when probing the module's TEXT.
>>>
>>> Below patch tries to resolve it.
>>>
>>> commit a949ae560a511fe4e3adf48fa44fefded93e5c2b
>>> Author: Steven Rostedt (Red Hat) <rostedt@...dmis.org>
>>> Date:   Thu Apr 24 10:40:12 2014 -0400
>>>
>>>      ftrace/module: Hardcode ftrace_module_init() call into load_module()
>>>
>>> But it can't fully resolve the issue.
>>>
>>> THis patch holds ftrace_mutex across ftrace_module_init and
>>> complete_formation.
>>>
>>> Signed-off-by: Qiu Peiyang <peiyangx.qiu@...el.com>
>>> Signed-off-by: Zhang Yanmin <yanmin.zhang@...el.com>
>> First, this patch has major whitespace damage. All tabs are now spaces!
> This seems very hackish, although I can't think of a better way at the
> moment. But I would like not to add more code into module.c if
> possible, and just use a notifier unless there's a real reason we can't
> (as there was when we added the hook in the first place).
> We would double-check it again. It's not a good idea to change common
> module codes.

I double-checked it. If using notifier, we have to add 2 new module notification
events in enum module_state.
For example, MODULE_STATE_INITING, MODULE_STATE_INITING_FAILED.
At MODULE_STATE_INITING, call ftrace_module_init(mod);
At MODULE_STATE_INITING_FAILED, call ftrace_release_mod (or similar function);
At MODULE_STATE_COMING, call a new function which links the new start_pg
to ftrace_pages.
Such design can also fix another bug in current kernel that ftrace start_pg
of the module is not cleaned up if complete_formation fails.
However, we change module common codes. The new events only serve ftrace.

If not holding ftrace_mutex across start_pg setup and complete_formation,
some other variables are not protected well, such like ftrace_pages, 
ftrace_start_up, and so on.

Yanmin
 

--
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/