linux-kernel - Re: [PATCH 00/13] perf_events: add support for sampling taken branches (v3)

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: <CABPqkBSALpYBTpaJo4Wor6weM-XM3PRxj23u8N+Kihvm36Hj8w@mail.gmail.com>
Date:	Tue, 24 Jan 2012 16:39:28 +0100
From:	Stephane Eranian <eranian@...gle.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	linux-kernel@...r.kernel.org, mingo@...e.hu, acme@...radead.org,
	robert.richter@....com, ming.m.lin@...el.com, andi@...stfloor.org,
	asharma@...com, ravitillo@....gov, vweaver1@...s.utk.edu
Subject: Re: [PATCH 00/13] perf_events: add support for sampling taken
 branches (v3)

Hi,

The branch stack sampling patch exposes a flaw in the sampling
buffer format as currently exported by the kernel.

In the current format, sample records (RECORD_SAMPLE) are NOT
self-describing. That means that by looking at the fixed size header, it
is not possible to determine which event caused the sample to be recorded
and what's in the body of the variable length sample.

Such introspection is only possible once we know the event unique id
(PERF_SAMPLE_ID). But to get the event ID, we need to parse the
sample. But, given that a sample has a variable length, there is no
predefined position for that ID in the sample. You have a chicken
and egg problem here. There is no room left in the fixed size header
to fit this in.

This works today with perf because perf applies the SAME sample_type
to ALL events, i.e., all events have the same body layout. This is a limitation
of the tool. The kernel API clearly allows more flexibility but it is
hindered by
the problem I described above.

With branch sampling, this becomes more problematic because if you
are sampling on many events, it may not be necessary nor useful to capture
the branch sample stack for each event. With existing HW, the branch
stack uses at most 264 bytes in a sample. You'd be consuming the buffer
space much faster for nothing.

We need to solve this problem yet maintain backward compatibility with old
version of tools.

The kernel sampling buffer format needs to evolve to have fixed size header
that are more self-describing. The header somehow needs to contain the event
ID or the sample_type for type=RECORD_SAMPLE. I would prefer the former
because if we ever need more than 64-bits for sample_type, we would have the
same problem again. Having the event ID, requires that it be generated
systematically. That is not the case today.

That new buffer format could be requested, as a flag, when the event is created.
That would ensure backward compatibility.

An alternative would be to find a way to encode the event ID at a known position
somehow in the body of a RECORD_SAMPLE. But I don't see how that would be
possible (given there is already the sample_id_all stuff).

Any comments?
--
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/