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: <20240904164429.hstbg5beejt32mlu@treble>
Date: Wed, 4 Sep 2024 09:44:29 -0700
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Borislav Petkov <bp@...en8.de>
Cc: Peter Zijlstra <peterz@...radead.org>, 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 Wed, Sep 04, 2024 at 02:39:18PM +0200, Borislav Petkov wrote:
> On Tue, Sep 03, 2024 at 09:28:29PM -0700, Josh Poimboeuf wrote:
> > 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.
> 
> This is more a question for my own understanding: so you want a generic
> approach where objtool doesn't need to know each special section and what it
> needs to copy there from but simply copy those new, special symbols over?
> 
> Which you use as markers of sorts: "this is a relevant symbol, pls copy it"...
> 
> I think you mean that but lemme confirm anyway.

Yes, that's exactly it.  I should clarify a bit more.

> Also, have you checked whether this can be done with some compiler switch
> already?

Not that I know of, since the compiler usually doesn't have visibility
to these sections.

It might be possible to specify "entsize" in the .pushsection flags,
which is an ELF section header attribute which objtool could read.

But that wouldn't work for .altinstr_replacement and other sections with
variable-size entries.  Also, "objtool klp diff" works by copying
symbols, so the current solution is definitely simpler as it fits in
nicely with the rest of the implementation.

-- 
Josh