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: <ZoVumd-b4CaRu5nW@bombadil.infradead.org>
Date: Wed, 3 Jul 2024 08:30:33 -0700
From: Luis Chamberlain <mcgrof@...nel.org>
To: Josh Poimboeuf <jpoimboe@...nel.org>
Cc: Petr Mladek <pmladek@...e.com>, 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 Tue, Jul 02, 2024 at 10:56:41PM -0700, Josh Poimboeuf wrote:
> 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?

I meant, that in the Rust world the symbols go over the allowed limit,
and so an alternative for them is to just use a hash. What I'm
suggesting is for a new kconfig option where that world is the
new one, so that they have to also do the proper userspace tooling
for it. Without that, I don't see it as properly tested or scalable.
And if we're gonna have that option for Rust for modules, then it begs
the question if this can be used by other users.

> > 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.

While it might solve this other issue, it doesn't solve the rust module
long symbol name issue.

  Luis