linux-kernel - Re: [RFC] New codectl(2) system call for sframe registration

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: <46d727ee-3675-4f99-92b3-3d9a8d54acaa@oracle.com>
Date: Wed, 23 Jul 2025 09:29:32 -0700
From: Indu Bhagat <indu.bhagat@...cle.com>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Steven Rostedt <rostedt@...dmis.org>
Cc: "Jose E. Marchesi" <jemarch@....org>, linux-kernel@...r.kernel.org,
        linux-trace-kernel@...r.kernel.org, bpf@...r.kernel.org,
        x86@...nel.org, Masami Hiramatsu <mhiramat@...nel.org>,
        Josh Poimboeuf
 <jpoimboe@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...nel.org>,
        Jiri Olsa <jolsa@...nel.org>, Namhyung Kim <namhyung@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andrii Nakryiko <andrii@...nel.org>,
        Beau Belgrave <beaub@...ux.microsoft.com>,
        Jens Remus
 <jremus@...ux.ibm.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Jens Axboe <axboe@...nel.dk>, Florian Weimer <fweimer@...hat.com>,
        Sam James <sam@...too.org>, Brian Robbins <brianrob@...rosoft.com>,
        Elena Zannoni <elena.zannoni@...cle.com>
Subject: Re: [RFC] New codectl(2) system call for sframe registration

On 7/23/25 8:09 AM, Mathieu Desnoyers wrote:
> On 2025-07-22 17:13, Steven Rostedt wrote:
>> On Tue, 22 Jul 2025 14:04:37 -0700
>> Indu Bhagat <indu.bhagat@...cle.com> wrote:
>>
>>> Yes and No.  The offset at which the text is loaded is _one_ part of the
>>> information to "fill in the blanks".  The other part is what to do with
>>> that information (text_vma) or how to relocate the SFrame section itself
>>> a.k.a. the relocation entries.  To know the relocations, one will need
>>> to get access to the respective relocation section, and hence access to
>>> the ELF section headers.
>>
>> You mean to find where in the sframe section itself that needs to be 
>> update?
>>
>> OK, that makes sense. So sframes does need to still be in an ELF file for
>> its own relocations and such.
>>
>> It will be interesting on how to do compression and on-demand page 
>> loading.
>>
>> There would need to be a table as well that will denote where in the
>> decompressed pages that relocations need to be performed.
> 
> If we can find a way to express all sframe "pointers" as offsets from a
> text_vma base, then there is no need for relocations. This would
> minimize complexity.
> 

(So we got into the topic of relocation in the context of compressing 
SFrame sections, the details of which are not chalked out yet.  As I 
mentioned SHF_ALLOC|SHF_COMPRESSED usecase needs to be discussed 
further.  But stating the following in case there has been a 
misunderstanding.)

The SFrame FDE func start addr field is indeed an offset from the field 
itself to the start PC of the function in the text section.  So in 
relocatable files (object files, or ld -r i.e. ET_REL), we see the 
relocations.

These relocations can be resolved at link time by the linker.  So for 
shared libraries and executables (ET_DYN, ET_EXEC), once the SFrame 
section in placed in the PT_LOAD segment, there are no relocations for 
readers/consumers.  These relocations remain for relocatable objects.

A consumer of relocatable object, e.g., in case of kernel modules, will 
need to take care of the relocations when adding the module.