linux-kernel - Re: [PATCH v2] On ppc64le we HAVE_RELIABLE

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180309174718.2700b29e@blackhole.lan>
Date:   Fri, 9 Mar 2018 17:47:18 +0100
From:   Torsten Duwe <duwe@....de>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     Michael Ellerman <mpe@...erman.id.au>,
        Jiri Kosina <jkosina@...e.cz>, linuxppc-dev@...ts.ozlabs.org,
        linux-kernel@...r.kernel.org, Nicholas Piggin <npiggin@...il.com>,
        live-patching@...r.kernel.org
Subject: Re: [PATCH v2] On ppc64le we HAVE_RELIABLE_STACKTRACE

On Thu, 8 Mar 2018 10:26:16 -0600
Josh Poimboeuf <jpoimboe@...hat.com> wrote:

> This doesn't seem to address some of my previous concerns:

You're right. That discussion quickly headed towards objtool
and I forgot about this one paragraph with the remarks.

> - Bailing on interrupt/exception frames

That is a good question. My current code keeps unwinding as long
as the trace looks sane. If the exception frame has a valid code
pointer in the LR slot it will continue. Couldn't there be cases
where this is desirable? Should this be configurable? Not that
I have an idea how this situation could occur for a thread
that is current or sleeping...

Michael, Balbir: is that possible? Any Idea how to reliably detect
an exception frame? My approach would be to look at the next return
address and compare it to the usual suspects (i.e. collect all 
"b ret" addresses in the EXCEPTION_COMMON macro, for BookS).

> - Function graph tracing return address conversion
> 
> - kretprobes return address conversion

You mean like in arch/x86/kernel/unwind_frame.c the call to
ftrace_graph_ret_addr ?

Forgive me my directness but I don't see why these should be handled in
arch-dependent code, other than maybe a hook, if inevitable, that calls
back into the graph tracer / kretprobes in order to get the proper
address, or simply call the trace unreliable in case it finds such a
return address.

I understand that x86 has a hard time with its multiple unwinders, but
there should be a simpler, generic solution for all other architectures.

	Torsten