linux-kernel - Re: ftrace performance impact with different configuration

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: <1325283941.24045.15.camel@gandalf.stny.rr.com>
Date:	Fri, 30 Dec 2011 17:25:41 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Philippe Rétornaz <philippe.retornaz@...l.ch>
Cc:	linux-arm-kernel@...ts.infradead.org, Rabin Vincent <rabin@....in>,
	leiwen@...vell.com, Lei Wen <adrian.wenl@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: ftrace performance impact with different configuration

On Fri, 2011-12-30 at 14:07 +0100, Philippe Rétornaz wrote:

> Sorry about being a bit naive, but why it is not possible to do it in two 
> steps ?
> call stop_machine to put the jmp which skip the call to mcount
> Then wait until all tasks hits schedule() (synchronize_sched() ?)

Here's the problem. With a preemptible kernel, hitting schedule() does
not mean that you can guarantee that all tasks have not been
interrupted.


	nop (use to be push lr)
	------------> interrupt
			set NEED_RESCHED
			end of interrupt
			preempt_schedule()
				schedule()

	[ another processes is now running ]
	call stop_machine()
	put in push lr
	call stop_machine()
	put in call to mcount

	everything seems to be running fine.

	the low priority task gets scheduled again...


				schedule() finishes
			preempt_schedule() finishes
			back at tail of return_from_intr in entry_64.S
			iret
	call mcount
			pop lr (which was never pushed)
			jmp lr

Now we jump back to some random stuff and the stack is corrupted.

There's no way to safely modify two instructions that depend on each
other in a preemptible kernel, with the exception of waiting for all
CPUs to hit idle (which may never happen on a busy system). And even
that may be racy.

-- Steve

> Then modify both instructions to put in place the two nops since we know that 
> nobody is calling mcount.


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