linux-kernel - Re: Coresight etmv4 enable over 32bit 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]

Message-ID: <CANLsYkzTGnPQ3FUPWYc-DOigvzMuTFTGqbbVTqqtVuCQW3esSA@mail.gmail.com>
Date:   Mon, 10 Dec 2018 11:01:55 -0700
From:   Mathieu Poirier <mathieu.poirier@...aro.org>
To:     adrian.wenl@...il.com
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        leiwen@...look.com
Subject: Re: Coresight etmv4 enable over 32bit kernel

Good day Adrian,

On Sat, 8 Dec 2018 at 05:05, Lei Wen <adrian.wenl@...il.com> wrote:
>
> Hi Mathieu,
>
> I am enabling etmv4 coresight over one Cortex-A7 soc, using 32bit kernel.
> And I am following [1] to do experiment regarding the addr_range feature.

That wiki is very old and after reading it again I seriously consider
removing it.  It is still accurate but there are better ways to do
things now, i.e perf.  The main openCSD documentation page [2]
contains everything you need to know about the integration with perf.

[2]. https://github.com/Linaro/OpenCSD/blob/master/HOWTO.md

> The default addr_range is set as _stext~_etext, and it works fine with
> etb as sink,
> and etm as source. I could see there are valid kernel addresses using OpenCSD.

I'm really curious about how you use openCSD to validate your traces -
can you  expand more on that?

I think the results are misleading you since the openCSD library can't
readily be used to decode sysfs trace sessions.  The wiki doesn't
mention using openCSD to decode traces either.  The only integrated
way to use openCSD to decode CoreSight traces is via perf.  Again, the
link above will give you all the information you need to do that.

>
> But while I try to store one small range of address pair, which contain only one
> kernel function. It doesn't behavior like what said in [1], the write
> pointer would
> grows rapidly with the read pointer. And I dump the etb buffer and parse it with
> openCSD, finding that there is no I_ASYNC packet in the dump and is fulled with
> I_NOT_SYNC.
>
> So my question is why ETB continue to grow when there is no trigger at all?
> Is it normal? I could provide more info if you need it.

I am dubious about the validation process and as such can't comment on
this.  Please share your results using the perf integration and then
I'll be able to have a better idea of what is going on.

Taking a step back I am curious about the ETMv4/ETB combination...  Is
the ETB the only sink you have to work with?  Moreover, are you sure
it is not a TMC-ETF?  The ETMv4/ETB match seems a little odd to me
since they belong to two different era of the CoreSight architecture.
Usually with an ETMv4 we will see a TMC-ETR, which as a lot more
capabilities.

Regards,
Mathieu

>
> [1]: https://wiki.linaro.org/WorklingGroups/Kernel/Coresight/traceDecodingWithDS5
>
> Thanks,
> Lei