linux-kernel - Re: [PATCH v8 4/8] ppc64 ftrace_with

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:	Tue, 16 Feb 2016 11:35:51 +0100
From:	Torsten Duwe <duwe@....de>
To:	Michael Ellerman <mpe@...erman.id.au>
Cc:	Balbir Singh <bsingharora@...il.com>,
	Jiri Kosina <jkosina@...e.cz>, Miroslav Benes <mbenes@...e.cz>,
	Petr Mladek <pmladek@...e.com>, Jessica Yu <jeyu@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
	live-patching@...r.kernel.org
Subject: Re: [PATCH v8 4/8] ppc64 ftrace_with_regs configuration variables

On Tue, Feb 16, 2016 at 09:09:16PM +1100, Michael Ellerman wrote:
> On Mon, 2016-02-15 at 15:04 +0100, Torsten Duwe wrote:
> > If you use "-pg -mprofile-kernel", gcc seems to forget that, and omits the TOC
> > load, for a similar assembler calling sequence.
> 
> That's by design.

Ah, ok.

> mprofile-kernel is supposed to create as little overhead as possible in the
> non-traced case. All of the burden is shifted to the trace function (_mcount).

... or its helpers, see below.

> The reason to do that is because modern distros always build with tracing, but
> most of the time tracing will not actually be active. So we want the cost of
> tracing-built-in-but-disabled to be ~zero.

Ok, that's a design goal.

> > That was the alternative I asked about; but given that the _mcount / ftrace_caller
> > trampoline hardly differs from a normal trampoline (so far), loading R2 would be the
> > general case, or an excessive special case handling would result.
> 
> I'm not sure I follow what you mean there at the end.

This suggests you have not yet actively debugged this problem ;-)

> Requiring ftrace_caller() to load the kernel TOC is not a problem IMHO.

The problem is, you don't get to ftrace_caller in the first place :)

> I think I have an easier way to do it, I'll reply to the patch with that (if it
> works).

I doubt so. Either it works, _or_ it is easier ;)

To save you some work: by the design of minimal overhead you try to follow,
SQUASH_TOC_SAVE_INSN from my patches isn't sufficient. You'll need to load the
_current_ TOC _on_ the trampoline, and in turn it will be different from the regular
trampolines; and that needs to be recognised, or the normal module linker logic
won't work.

OTOH my proposed GCC change only affects a very limited number of functions...

Looking forward to your patch!

	Torsten