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] [day] [month] [year] [list]

Message-ID: <85aa82ce-dde4-4ffa-8180-6616f72d6580@oracle.com>
Date: Wed, 5 Feb 2025 17:10:47 -0800
From: Indu Bhagat <indu.bhagat@...cle.com>
To: Josh Poimboeuf <jpoimboe@...nel.org>
Cc: Andrii Nakryiko <andrii.nakryiko@...il.com>, 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,
        Jens Remus <jremus@...ux.ibm.com>,
        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 2/4/25 4:57 PM, Josh Poimboeuf wrote:
> On Thu, Jan 30, 2025 at 01:39:52PM -0800, Indu Bhagat wrote:
>> On 1/28/25 6:02 PM, Josh Poimboeuf wrote:
>>> However, if we're going that route, we might want to even consider a
>>> completely revamped data layout.  For example:
>>>
>>> One insight is that the vast majority of (cfa, fp, ra) tuples aren't
>>> unique.  They could be deduped by storing the unique tuples in a
>>> standalone 'fre_data' array which is referenced by another
>>> address-specific array.
>>>
>>>     struct fre_data {
>>> 	s8|s16|s32 cfa, fp, ra;
>>> 	u8 info;
>>>     };
>>>     struct fre_data fre_data[num_fre_data];
>>>
>>
>> We had the same observation at the time of SFrame V1.  And this method of
>> compaction (deduped tuples) was brain-stormed a bit.  Back then, the costs
>> were thought to be:
>>    - more work at build time.
>>    - an additional data access once the FRE is found (as there is
>> indirection).
>>
>> So it was really compaction at the costs above.  We did steer towards
>> simplicity and the SFrame FRE is what it stands today.
>>
>> The difference in the pros and cons now from then:
>>    - pros: helps mitigate unaligned accesses
>>    - cons: interferes slightly with the design goal of efficient addition and
>> removal of stack trace information per function for JIT. Think "removal" as
>> the set of actions necessary for addressing fragmentation in SFrame section
>> data in JIT usecase.
> 
> If fre_data[] is allowed to have duplicates then the deduping could be
> optional.
> 
>>> Note FDEs aren't even needed here as the unwinder doesn't need to know
>>> when a function begins/ends.  The only info needed by the unwinder is
>>> just the fre_data struct.  So a simple binary search of fres[] is all
>>> that's really needed.
>>
>> Splitting out information (start_address) to an FDE (as done in V1/V2) has
>> the benefit that a job like relocating information is proportional to
>> O(NumFunctions).
>>
>> In the case above, IIUC, where the proposal puts start_address in the FRE,
>> these costs will be (much) higher.
> 
> I'm not sure I follow, is this referring to the link-time work of
> sorting things?
> 

I meant the work of tracking the start address of each function.  This 
could be done at link-time as is done in most cases.

But also depending on the case : e.g., kernel module loader will need to 
apply these relocations in the .rela.sframe section...

If the granularity is finer than a function, more number of relocations 
will need to be applied.

>> In addition, not being able to identify stack trace information per function
>> will affect the JIT usecase.  We need to able to mark stack trace
>> information stale for functions in JIT environment.
> 
> Maybe, though it's hard to really say how any of these changes would
> affect JIT without knowing what those interfaces are going to look like.
>