linux-kernel - Re: [RFC] perf record: missing buildid for callstack modules

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]

Date:	Fri, 15 Jan 2016 10:34:36 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Stephane Eranian <eranian@...gle.com>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Namhyung Kim <namhyung@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Jiri Olsa <jolsa@...nel.org>,
	Namhyung Kim <namhyung@...nel.org>,
	Adrian Hunter <adrian.hunter@...el.com>,
	"ak@...ux.intel.com" <ak@...ux.intel.com>
Subject: Re: [RFC] perf record: missing buildid for callstack modules

On Thu, Jan 14, 2016 at 05:59:48PM -0800, Stephane Eranian wrote:
> Peter,
> 
> On Thu, Jan 14, 2016 at 3:36 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> > On Thu, Jan 14, 2016 at 12:27:34PM +0100, Ingo Molnar wrote:
> >> > +    *      u32                             filename_len;
> >> > +    *      char                            filename[2+];
> >
> >> Acked-by: Ingo Molnar <mingo@...nel.org>
> >
> > except of course that sizeof(u32) == 4 :/

> There is no padding here. Are you concerned about running out of bits
> in filename_len?

No, I just made a mess of it :-)

filename_len should have been u16 and filename should then be 6+8n in
size.

> Any extension possible because header.size - sizeof(mmap3) -
> filename_len sizing what's after filename, right?

Right, current MMAP records use the remaining size as the filename
length, but by explicitly specifying that we can add optional fields.

These fields must be after filename_len, otherwise you'd not be able to
find filename_len and you could not compute the extra size. And given
alignment constraints it makes sense to do it after filename[].

So suppose we wanted to also add atime and ctime, we could do.

  PERF_RECORD_MMAP3 {
    ...
    u16 filename_len;
    char filename[6+8n];

    if (extra_size >= 16) {
      u64 stime;
      u64 ctime;
    };
  }

or something like that.