linux-kernel - Re: [RFC] Merging ftrace_stack, perf_callchain, oprofile->backtrace and stack

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] [day] [month] [year] [list]

Message-ID: <20181022152612.ex5hkipgm5uzjrt5@ryuk>
Date:   Tue, 23 Oct 2018 02:26:12 +1100
From:   Aleksa Sarai <cyphar@...har.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Robert Richter <rric@...nel.org>,
        Brendan Gregg <bgregg@...flix.com>,
        linux-kernel@...r.kernel.org, oprofile-list@...ts.sf.net
Subject: Re: [RFC] Merging ftrace_stack, perf_callchain, oprofile->backtrace
 and stack_trace

On 2018-10-21, Peter Zijlstra <peterz@...radead.org> wrote:
> > Hi all,
> > 
> > I'm currently working on a patchset to make kretprobes produce
> > reasonable stack traces[1], and it appears this is a generic problem
> > across the entire kernel -- you can see the same kretprobe_trampoline()
> > issue when using ftrace just as much as bpf_trace.
> > 
> > However, in working on this patch, I've noticed that there appear to be
> > several different implementations of "get the stack trace from this
> > pt_regs" which all appear quite similar. Namely:
> > 
> >   * struct ftrace_stack;
> >   * struct perf_callchain_entry; [**]
> >   * struct stack_trace;
> 
> the perf thing also does userspace stack, where the others do not afaik.

Ah right, I forgot about that. Though I wonder whether there would be a
strong argument against extending 'struct stack_trace' to contain the
ustack so we could use it then.

> And for the kernel part it already uses the regular kernel unwinder.
> I'm not sure what you're proposing.

They do use the kernel unwinder, but they are both implemented
per-architecture and use different structures to store and represent the
stack trace (even though at the end of the day they are just an array of
longs).

oprofile for instance (appears to) reimplement the following code
per-architecture:

  struct stack_trace trace;
  save_stack_trace(&trace);
  print_stack_trace(&trace, 0);

The same applies for perf_callchain_entry which is all implemented
per-architecture even though get_perf_callchain_kernel() could just
re-use save_stack_trace_regs().

But after looking at this a bit more, I think I'll write a patch which
does this the "silly" way and then I'll see whether maintainers prefer
it to be refactored.

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)