linux-kernel - RE: ftrace trace_raw

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

Message-ID: <8b225fdcbe6e4cc7bba302d899e277ae@AcuMS.aculab.com>
Date:   Tue, 7 Jan 2020 13:49:40 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Steven Rostedt' <rostedt@...dmis.org>
CC:     "'linux-kernel@...r.kernel.org'" <linux-kernel@...r.kernel.org>
Subject: RE: ftrace trace_raw_pipe format

After reading the code in kbuffer-parse.c I can now get a sequence of trace entries
with their timestamps.

I think there is a bug in the processing (skipping) of KBUFFER_TYPE_TIME_STAMP
in translate_data().
I assume a 64bit timestamp would follow, and 'data' should only be incremented
by 8 (not 12) as there is an increment by 4 earlier.
I'm pretty sure these are never generated - __next_event() doesn't loop.

It is ~impossible to match this parsing code to the generating code because none
of the constants are in a shared header file.

Back to my original problem:

I've a set of trace files that contain 4 4k blocks each.
The 4 blocks are in time order, but I think there is a big time discontinuity
between the first and second blocks.
The second block has both MISSED_EVENTS and MISSED_STORED set.
My suspicion is that the first block (partially filled) is the final block
from the previous trace and its presence is a bug.
So anything processing the trace must completely ignore the first
block (if the second reports MISSED_EVENTS).

The 4th block is also partial - which is what I expect.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)