linux-kernel - [BUG] perf_event: sampling buffer format cannot handle multi-event sampling

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

Message-ID: <BANLkTi=g6iPgdctAmuZ=bb8J6FqNJA-vZQ@mail.gmail.com>
Date:	Tue, 19 Apr 2011 19:10:49 +0000
From:	Stephane Eranian <eranian@...gle.com>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>, mingo@...e.hu,
	Paul Mackerras <paulus@...ba.org>,
	Robert Richter <robert.richter@....com>,
	Andi Kleen <andi@...stfloor.org>
Subject: [BUG] perf_event: sampling buffer format cannot handle multi-event sampling

Hi,

I was looking at the sampling buffer format and I think there is an
issue in case
one samples on more than one event at a time and each event as a different
sample_type value (i.e., what it wants to record in each sample).

The sample_type is exported per-event by the API. In order to decode a sample
(PERF_RECORD_SAMPLE) one has to know which event caused it. To identify
the event, one has to include PERF_SAMPLE_ID in the sample_type. Each such
id uniquely identifies an event. Assuming the tool keeps a mapping of event to
ID, we can then reconstruct. This is what perf does.

The problem is that to extract the event ID, one has to already parse the sample
itself. That means, you need sample_type to extract the event ID.

Thus, we have a catch 22 situation.

Looking at the perf tool, it sort of works today simply because the
same sample_type
is applied to all events.

To solve this, we could either:
   - add the event ID to the header for PERF_RECORD_SAMPLE
   - enforce event ID is systematically saved at the beginning on
PERF_RECORD_SAMPLE

None of those options is transparent, I am afraid, unless we introduce
new record types.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/