linux-kernel - Re: [PATCH 0/1] Support PERF_SAMPLE_READ with inherit

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: <Zar9xXlPmCM2vtAk@tassilo>
Date: Fri, 19 Jan 2024 14:55:01 -0800
From: Andi Kleen <ak@...ux.intel.com>
To: Ben Gainey <Ben.Gainey@....com>
Cc: "irogers@...gle.com" <irogers@...gle.com>,
	"alexander.shishkin@...ux.intel.com" <alexander.shishkin@...ux.intel.com>,
	James Clark <James.Clark@....com>,
	"peterz@...radead.org" <peterz@...radead.org>,
	Mark Rutland <Mark.Rutland@....com>,
	"linux-perf-users@...r.kernel.org" <linux-perf-users@...r.kernel.org>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"acme@...nel.org" <acme@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"jolsa@...nel.org" <jolsa@...nel.org>,
	"namhyung@...nel.org" <namhyung@...nel.org>,
	"adrian.hunter@...el.com" <adrian.hunter@...el.com>
Subject: Re: [PATCH 0/1] Support PERF_SAMPLE_READ with inherit_stat

> I had considered that, but given currently this perf_event_attr
> configuration is not allowed, I assumed that it would require existing
> tools to add support which would in effect be an opt-in. Of course,
> adding a new flag to be explicit would be trivial enough if required.

That's fair. Makes sense.

> That said, the binary format for the mmap records / read() etc does not
> change so using an unmodified tool to parse the data file will give bad
> results. Therefore any workflow where "modified recording tool" can be
> combined with "older / unmodified parsing tool" will break. Not sure of
> the best way to handle this... presumably whenever a change is made to
> the perf record format, any workflow that allows old parsers to read
> new format data without version checks could fail? Admittedly this is a
> "looks the same but isn't" change so harder for tools devs to spot. Any
> suggestions?

For perf itself we can find something. It does a couple of checks, like
reserved bits in the perf_event_attr. For the general case of other
parsers it's unclear. I suppose could increment the magic identifier
to PERFILE3

-Andi