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: <CAEf4Bza2npJdh-aBcH98aNjiuwuw_kRB1fnMfTGCr+Y_Yv8gWA@mail.gmail.com>
Date: Wed, 5 Feb 2025 15:05:14 -0800
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Jens Remus <jremus@...ux.ibm.com>
Cc: Indu Bhagat <indu.bhagat@...cle.com>, Josh Poimboeuf <jpoimboe@...nel.org>, 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 Wed, Feb 5, 2025 at 3:02 AM Jens Remus <jremus@...ux.ibm.com> wrote:
>
> 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];
> };
>

yeah, sorry, copy/paste error for those sfre_info, it's always u8

> 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.
>

yep

> 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/
>