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 15:53:59 +1100
From:	Balbir Singh <bsingharora@...il.com>
To:	Torsten Duwe <duwe@....de>, Michael Ellerman <mpe@...erman.id.au>
Cc:	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 Mon, 2016-02-15 at 23:21 +0100, Torsten Duwe wrote:
> On Mon, Feb 15, 2016 at 03:04:08PM +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.
> > 
> > Looking at the code I can _understand_ why this is so, but my GCC knowledge
> > is not that deep that I could easily _fix_ this reliably.
> 
> Nonetheless, here's a proposal.
> 
> --- a/gcc/config/rs6000/rs6000.c
> +++ b/gcc/config/rs6000/rs6000.c
> @@ -25154,6 +25154,10 @@ rs6000_emit_prologue (void)
>      {
>        cfun->machine->r2_setup_needed = df_regs_ever_live_p (TOC_REGNUM);
>  
> +      /* Profiling _will_ generate a call to a global _mcount. */
> +      if (crtl->profile)
> +	cfun->machine->r2_setup_needed = true;
> +
>        /* With -mminimal-toc we may generate an extra use of r2 below.  */
>        if (TARGET_TOC && TARGET_MINIMAL_TOC && get_pool_size () != 0)
>  	cfun->machine->r2_setup_needed = true;

I was wondering if ftrace() works correctly, specifically dynamic ftrace.
We should be able to get livepatching to work as well. I can see r2 being
saved in the stub in ftrace_caller in patch 2/8

+       mr      r0,r2   /* save callee's TOC */
+       addis   r2,r12,(.TOC.-ftrace_caller-12)@ha
+       addi    r2,r2,(.TOC.-ftrace_caller-12)@l

The only limitation today is figuring out the correct offset to patch
(8 or 16) depending on whether the TOC stub is generated or not by the
compiler

If the sequence is well known, we could potentially scan instructions
or go to the hash that ftrace maintains and search in there with an offset
of 8 to 16.

Balbir Singh