linux-kernel - Re: [RFC PATCH 0/4] Integration of function trace with System Trace IP blocks

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]

Message-ID: <87d1ntqnm9.fsf@ashishki-desk.ger.corp.intel.com>
Date:	Tue, 07 Jun 2016 13:50:22 +0300
From:	Alexander Shishkin <alexander.shishkin@...ux.intel.com>
To:	Chunyan Zhang <zhang.chunyan@...aro.org>, rostedt@...dmis.org,
	mathieu.poirier@...aro.org, mingo@...hat.com
Cc:	mike.leach@....com, tor@...com, maxime.coquelin@...com,
	philippe.langlais@...com, nicolas.guion@...com,
	zhang.lyra@...il.com, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC PATCH 0/4] Integration of function trace with System Trace IP blocks

Chunyan Zhang <zhang.chunyan@...aro.org> writes:

> This patchset is an RFC aimed at generating ideas on the best way to
> use STM IP blocks to collect function tracing information produced by
> Ftrace.  That way logging information generated by the function trace
> subsystem and gathered in the coresight sink can be used in conjunction
> with trace data from other board components, also collected in the same
> trace sink.  This example is using ARM coresight STM but the same would
> apply to any architecture wishing to do the same.

I'd say, traces are only useful if you can make sense of them. This
patchset basically sends out addresses, which only makes sense if the
decoding side has vmlinux of the kernel under tracing. But even if they
do, other context information is still missing, such as the cpu ids of
these events, without which you can't really tell what's been going
on. You can, of course, still use this data for coverage analysis, but
there are easier ways of doing that already.

So I'd say that first you need to export at least as much as is written
to the ftrace ring buffer. And perhaps, to avoid inventing yet another
binary protocol, it would have to be exactly what is written to the
ftrace ring buffer.

Then you need to think whether you want to export binary ftrace data or
ascii-formatted strings:
  * binary data is way less overhead;
  * ascii data is self-contained;
  * binary data requires the exact running kernel's binaries to decode
  and the ability to read them (say, if you wanted to read the traces on
  some other OS that doesn't have native support for ELF binaries);
  every time you recompile the target kernel, you'll have to copy it
  over to the debug host;
  * ascii data can be looked at independently.

That's off the top of my head.

Regards,
--
Alex