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: <CAG2=9p_KR6gXDBo9ucvyUrrzbdA6zLE15aRE+MPHrm4Edy3Sjw@mail.gmail.com>
Date:	Wed, 8 Jun 2016 19:01:51 +0800
From:	Chunyan Zhang <zhang.chunyan@...aro.org>
To:	Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Mathieu Poirier <mathieu.poirier@...aro.org>, mingo@...hat.com,
	Mike Leach <mike.leach@....com>, Tor Jeremiassen <tor@...com>,
	Maxime Coquelin <maxime.coquelin@...com>,
	philippe.langlais@...com, Nicolas GUION <nicolas.guion@...com>,
	Lyra Zhang <zhang.lyra@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC PATCH 0/4] Integration of function trace with System Trace
 IP blocks

Hi Alex,

Thanks for your comments on every patch of this serial.

On Tue, Jun 7, 2016 at 6:50 PM, Alexander Shishkin
<alexander.shishkin@...ux.intel.com> wrote:
> 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

I guess it shouldn't hard to be implemented.

> do, other context information is still missing, such as the cpu ids of

On ARM Platform, STM master IDs are related with CPU cores, so long as
we know which master the traces come from, we know the CPU id it
happened on.  Doesn't Intel STM have this kind of similar mechanism?

> 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.

In order to minimize overhead introduced by exporting message to STM,
we perhaps cannot record as much information as is exported to Ftrace
ring buffer.  The pointers of function and its parent function may not
be enough though, we can see what else is required.  But we may not
need such as timestamp, cpuid, since CoreSight has its own timestamp
and I guess Intel STM is the same;  About the cpuid for Intel STM, can
we have some way to know that, for example using different channel to
identify that?

>
> Then you need to think whether you want to export binary ftrace data or
> ascii-formatted strings:
>   * binary data is way less overhead;

Right, that's why I changed to this way, I sent out one patchset
before in which ascii-formatted strings was recorded to STM, but
adding that process introduced too much overhead to be accepted for
Ftrace subsystem, I dropped that solution.

>   * 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;

Yes. I think if we want to use this feature, we have to make vmlinux
as a part of the decoding library.

>   * ascii data can be looked at independently.

Above all are my superficial opinions, please correct me if I'm
missing something, and will appreciate if you can give more
suggestions/opinions.

Thanks,
Chunyan

>
> That's off the top of my head.
>
> Regards,
> --
> Alex