linux-kernel - Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is broken in RCU code

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: <20170511135246.GN3452@pathway.suse.cz>
Date:   Thu, 11 May 2017 15:52:46 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Josh Poimboeuf <jpoimboe@...hat.com>, Jessica Yu <jeyu@...hat.com>,
        Jiri Kosina <jikos@...nel.org>,
        Miroslav Benes <mbenes@...e.cz>,
        "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
        live-patching@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is
 broken in RCU code

On Mon 2017-05-08 15:13:22, Steven Rostedt wrote:
> On Mon, 8 May 2017 11:51:08 -0500
> Josh Poimboeuf <jpoimboe@...hat.com> wrote:
> 
> > Another idea would be to figure out a way to stop using RCU in
> > klp_ftrace_handler() altogether.
> > 
> 
> That may work if rcu_enter_irq() doesn't. But that's how NMIs use rcu.

I am a bit confused by the above. Does it mean that RCU could not be
used in NMI handlers?


Anyway, a crazy idea is to use the livepatch consistency model instead
of RCU to protect the function stack. The model makes sure that all
tasks, including the idle ones, were not running any patched function
(and their ftrace handlers) at some point. It should be safe
but I am not sure if it is worth it.

Alternatively, it might be enough to use the probably more lightwight
solution that is used when ftrace handlers are deregistered, I mean:

	/*
	 * We need to do a hard force of sched synchronization.
	 * This is because we use preempt_disable() to do RCU, but
	 * the function tracers can be called where RCU is not watching
	 * (like before user_exit()). We can not rely on the RCU
	 * infrastructure to do the synchronization, thus we must do it
	 * ourselves.
	 */
	schedule_on_each_cpu(ftrace_sync);

	/*
	 * When the kernel is preeptive, tasks can be preempted
	 * while on a ftrace trampoline. Just scheduling a task on
	 * a CPU is not good enough to flush them. Calling
	 * synchornize_rcu_tasks() will wait for those tasks to
	 * execute and either schedule voluntarily or enter user space.
	 */
	if (IS_ENABLED(CONFIG_PREEMPT))
		synchronize_rcu_tasks();



Best  Regards,
Petr