linux-kernel - Re: [PATCH] kallsyms, livepatch: Fix livepatch with CONFIG_LTO

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: <20240703055641.7iugqt6it6pi2xy7@treble>
Date: Tue, 2 Jul 2024 22:56:41 -0700
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Petr Mladek <pmladek@...e.com>
Cc: Luis Chamberlain <mcgrof@...nel.org>, Miroslav Benes <mbenes@...e.cz>,
	Sami Tolvanen <samitolvanen@...gle.com>, Song Liu <song@...nel.org>,
	live-patching@...r.kernel.org, linux-kernel@...r.kernel.org,
	jikos@...nel.org, joe.lawrence@...hat.com, nathan@...nel.org,
	morbo@...gle.com, justinstitt@...gle.com,
	thunder.leizhen@...wei.com, kees@...nel.org, kernel-team@...a.com
Subject: Re: [PATCH] kallsyms, livepatch: Fix livepatch with CONFIG_LTO_CLANG

On Mon, Jul 01, 2024 at 03:13:23PM +0200, Petr Mladek wrote:
> So, you suggest to search the symbols by a hash. Do I get it correctly?
> 
> Well, it might bring back the original problem. I mean
> the commit 8b8e6b5d3b013b0 ("kallsyms: strip ThinLTO hashes from
> static functions") added cleanup_symbol_name() so that user-space
> tool do not need to take care of the "unstable" suffix.

Are symbol names really considered user ABI??  That's already broken by
design.  Even without LTO, the toolchain can mangle them for a variety
of reasons.

If a user space tool doesn't want the suffixes, surely it can figure out
a way to deal with that on their own?

> So, it seems that we have two use cases:
> 
>    1. Some user-space tools want to ignore the extra suffix. I guess
>       that it is in the case when the suffix is added only because
>       the function was optimized.
> 
>       It can't work if there are two different functions of the same
>       name. Otherwise, the user-space tool would not know which one
>       they are tracing.
> 
> 
>    2. There are other use-cases, including livepatching, where we
>       want to be 100% sure that we match the right symbol.
> 
>       They want to match the full names. They even need to distinguish
>       symbols with the same name.
> 
> 
> IMHO, we need a separate API for each use-case.

We should just always link with -zunique-symbols so the duplicate
symbols no longer exist.  That would solve a lot of problems.

-- 
Josh