[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240906101909.GAZtrXHVweqJJ2j82v@fat_crate.local>
Date: Fri, 6 Sep 2024 12:19:09 +0200
From: Borislav Petkov <bp@...en8.de>
To: Josh Poimboeuf <jpoimboe@...nel.org>
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>, Michael Matz <matz@...e.de>
Subject: Re: [RFC 28/31] x86/alternative: Create symbols for special section
entries
On Wed, Sep 04, 2024 at 09:44:29AM -0700, Josh Poimboeuf wrote:
> 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.
Right, I was talking to Michael about it yesterday, CCed.
He suggested that you might be better off creating these annotations by
sticking the required info in a section instead of generating symbols.
I.e.,
.pushsection .klp_objects
.size \\name\\@, \\end - .\n"
...
.popsection
and so this section will be completely out of the way, you won't pollute the
symbol table with countless fake symbols and you can simply parse that section
to get the info you need.
Right?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists