linux-kernel - Re: [PATCH v4 17/39] unwind_user/sframe: Add support for reading .sframe headers

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: <0837be81-ec2e-4dac-bc42-91c626c22b9a@linux.ibm.com>
Date: Wed, 5 Feb 2025 12:01:55 +0100
From: Jens Remus <jremus@...ux.ibm.com>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>,
        Indu Bhagat <indu.bhagat@...cle.com>,
        Josh Poimboeuf <jpoimboe@...nel.org>
Cc: x86@...nel.org, Peter Zijlstra <peterz@...radead.org>,
        Steven Rostedt <rostedt@...dmis.org>, Ingo Molnar <mingo@...nel.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        linux-kernel@...r.kernel.org, Mark Rutland <mark.rutland@....com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...nel.org>, Namhyung Kim <namhyung@...nel.org>,
        Ian Rogers <irogers@...gle.com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        linux-perf-users@...r.kernel.org, Mark Brown <broonie@...nel.org>,
        linux-toolchains@...r.kernel.org, Jordan Rome <jordalgo@...a.com>,
        Sam James <sam@...too.org>, linux-trace-kernel@...r.kernel.org,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Florian Weimer <fweimer@...hat.com>, Andy Lutomirski <luto@...nel.org>,
        Masami Hiramatsu <mhiramat@...nel.org>, Weinan Liu <wnliu@...gle.com>
Subject: Re: [PATCH v4 17/39] unwind_user/sframe: Add support for reading
 .sframe headers

On 28.01.2025 02:10, Andrii Nakryiko wrote:

> So, currently in v2, FREs within FDEs use an array-of-structs layout.
> If we use preudo-C type definitions, it would be something like this
> for FDE + its FREs:
> 
> struct FDE_and_FREs {
>      struct sframe_func_desc_entry fde_metadata;
> 
>      union FRE {
>          struct FRE8 {
>              u8 sfre_start_address;
>              u8 sfre_info;
>              u8|u16|u32 offsets[M];
>          }
>          struct FRE16 {
>              u16 sfre_start_address;
>              u16 sfre_info;
>              u8|u16|u32 offsets[M];
>          }
>          struct FRE32 {
>              u32 sfre_start_address;
>              u32 sfre_info;
>              u8|u16|u32 offsets[M];
>          }
>      } fres[N] __packed;
> };
> 
> where all fres[i]s are one of those FRE8/FRE16/FRE32, so start
> addresses have the same size, but each FRE has potentially different
> offsets sizing, so there is no common alignment, and so everything has
> to be packed and unaligned.

Just for clarification of the SFrame V2 format, as there may be some
misconception. Using pseudo-C type definition:

struct sframe_fre8 {
	u8 sfre_start_address;
	u8 sfre_info;
	s8|s16|s32 offsets[M];
};
struct sframe_fre16 {
	u16 sfre_start_address;
	u8 sfre_info;
	s8|s16|s32 offsets[M];
};
struct sframe_fre32 {
	u32 sfre_start_address;
	u8 sfre_info;
	s8|s16|s32 offsets[M];
};

struct sframe_section {
	/* Headers. */
	struct sframe_preamble preamble;
	struct sframe_header header;
	struct sframe_auxiliary_header auxhdr;

	/* FDEs. */
	struct sframe_fde fdes[N_FDE];

	/* FRE8s / FRE16s / FRE32s per FDE. */
	struct sframe_fre{8|16|32} fres_fde1[N_FRE_FDE1] __packed;
	...
	struct sframe_fre{8|16|32} fres_fdeN[N_FRE_FDEN] __packed;
};

Where:
- fdes[] can be binary searched: All fdes[i] are of equal size and
   sorted on start address.
- Each fdes[i] points at its fres_fdei[].
- fres_fdei[] cannot be binary searched: For each fdes[i] they are
   one of those FRE8/FRE16/FRE32, so start addresses have the same
   size, but each FRE has potentially different offsets sizing, so
   there is no common alignment, and so everything has to be packed
   and unaligned.

Regards,
Jens
-- 
Jens Remus
Linux on Z Development (D3303)
+49-7031-16-1128 Office
jremus@...ibm.com

IBM

IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Böblingen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/