linux-kernel - Re: [RFC 28/31] x86/alternative: Create symbols for special section entries

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: <20240904080842.GE4723@noisy.programming.kicks-ass.net>
Date: Wed, 4 Sep 2024 10:08:42 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Josh Poimboeuf <jpoimboe@...nel.org>
Cc: live-patching@...r.kernel.org, linux-kernel@...r.kernel.org,
	x86@...nel.org, Miroslav Benes <mbenes@...e.cz>,
	Petr Mladek <pmladek@...e.com>,
	Joe Lawrence <joe.lawrence@...hat.com>,
	Jiri Kosina <jikos@...nel.org>,
	Marcos Paulo de Souza <mpdesouza@...e.com>,
	Song Liu <song@...nel.org>
Subject: Re: [RFC 28/31] x86/alternative: Create symbols for special section
 entries

On Tue, Sep 03, 2024 at 09:28:29PM -0700, Josh Poimboeuf wrote:
> On Tue, Sep 03, 2024 at 10:29:09AM +0200, Peter Zijlstra wrote:
> > On Mon, Sep 02, 2024 at 09:00:11PM -0700, Josh Poimboeuf wrote:
> > > Create a symbol for each special section entry.  This helps objtool
> > > extract needed entries.
> > 
> > A little more explanation would be nice,..
> 
> Indeed!
> 
> From: Josh Poimboeuf <jpoimboe@...nel.org>
> Subject: [PATCH] x86/alternative: Create symbols for special section entries
> 
> The kernel has a myriad of special sections including __bug_table,
> .altinstructions, etc.  Each has its own distinct format, though each is
> more or less an array of structs or pointers.
> 
> When creating a livepatch module, objtool extracts a subset of functions
> out of the original object file and into a new one.  For that to work
> properly, it also needs to extract a subset of each special section's
> entries.  Specifically, it should only extract those entries which
> reference the extracted functions.
> 
> One way to achieve that would be to hardcode intimate knowledge about
> each special section and its entry sizes.  That's less than ideal,
> especially for cases like .altinstr_replacement which has variable-sized
> "structs" which are described by another section.
> 
> Take a more generic approach: for the "array of structs" style sections,
> annotate each struct entry with a symbol containing the entry.  This
> makes it easy for tooling to parse the data and avoids the fragility of
> hardcoding section details.
> 
> (For the "array of pointers" style sections, no symbol is needed, as the
> format is already self-evident.)

(so someone went and touched a ton of the alternative code recently,
this is going to need a rebase)

This generates a metric ton of symbols and I'm not seeing you touch
kallsyms.c, do we want to explicitly drop these from a --all-symbols
build? I don't think it makes sense to have them in the final image,
right?