linux-kernel - Re: [PATCH v8 1/8] ppc64 (le): prepare for -mprofile-kernel

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:	Wed, 17 Feb 2016 22:39:13 +1100
From:	Michael Ellerman <mpe@...erman.id.au>
To:	Torsten Duwe <duwe@....de>
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 1/8] ppc64 (le): prepare for -mprofile-kernel

On Wed, 2016-02-17 at 12:30 +0100, Torsten Duwe wrote:
> On Wed, Feb 17, 2016 at 09:55:40PM +1100, Michael Ellerman wrote:
> > 
> > On a kernel built with the 2 instruction version this will fault when the
> > function we're looking at is located at the beginning of a page. Because
> > instruction[-3] goes off the front of the mapping.
> > 
> > We can probably fix that. But it's still a bit dicey.
> 
> Not necessarily. Now that it's a separate function, it can be nested a bit deeper,
> so we don't take chances on compiler optimisation:
> 
> if (instruction[-2] == PPC_INST_STD_LR) /* where should R0 come from? there must be... */
>   {
>     if (instruction[-3] == PPC_INST_MFLR)
>       return 1;
>   }
> else if (instruction[-2] == PPC_INST_MFLR)
>     return 1;
> return 0;

Yeah true that should work in practice.

It's still trivial to construct a module that will oops the loader, but I guess
that's always been true.

> > I'm wondering if we want to just say we only support the 2 instruction version.
> > Currently that means GCC 6 only, or a distro compiler with the backport of
> > e95d0248dace. But we could also ask GCC to backport it to 4.9 and 5.
> 
> IMHO that's a too weak reason for a too strong limitation. OTOH getting everyone
> to use the 2 insn version sounds appealing...

Fair enough. I'm just trying to manage the complexity explosion.

I'd certainly advocate that you backport it to your toolchain.

> Is e95d0248dace self-sufficient or does it depend on other improvements?

AFAIK it's self sufficient, it just deletes a single line. I'll ask the GCC
guys tomorrow if they can backport it if you don't beat me to it :)

cheers