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: <CABCJKucSUA_fc1eWecWAZ3z8J-T=s5zsZunJHF2VgB=9V5c3tA@mail.gmail.com>
Date: Mon, 8 Jul 2024 17:07:05 -0700
From: Sami Tolvanen <samitolvanen@...gle.com>
To: Luis Chamberlain <mcgrof@...nel.org>, Matthew Maurer <mmaurer@...gle.com>
Cc: Petr Mladek <pmladek@...e.com>, Gary Guo <gary@...yguo.net>, 
	Masahiro Yamada <masahiroy@...nel.org>, Michal Suchánek <msuchanek@...e.de>, 
	Lucas De Marchi <lucas.demarchi@...el.com>, Andreas Hindborg <nmi@...aspace.dk>, 
	Josh Poimboeuf <jpoimboe@...nel.org>, Miroslav Benes <mbenes@...e.cz>, 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 8, 2024 at 2:33 PM Luis Chamberlain <mcgrof@...nel.org> wrote:
>
> Looking at this again its not to me why Masahiro Yamada's suggestion on
> that old patch series to just increase the length and put long symbols
> names into its own section [0] could not be embraced with a new kconfig
> option, so new kernels and new userspace could support it:
>
> https://lore.kernel.org/lkml/CAK7LNATsuszFR7JB5ZkqVS1W=hWr9=E7bTf+MvgJ+NXT3aZNwg@mail.gmail.com/

Matt, was there a reason we didn't move forward with Masahiro's
proposal? It sounds reasonable to me, but I might be missing some
background here.

> > I am a bit scared because using hashed symbol names in backtraces, gdb,
> > ... would be a nightmare. Hashes are not human readable and
> > they would complicate the life a lot. And using different names
> > in different interfaces would complicate the life either.
>
> All great points.
>
> The scope of the Rust issue is self contained to modversion_info,
> whereas for CONFIG_LTO_CLANG issue commit 8b8e6b5d3b013b0
> ("kallsyms: strip ThinLTO hashes from static functions") describes
> the issue with userspace tools (it doesn't explain which ones)
> which don't expect the function name to change. This seems to happen
> to static routines so I can only suspect this isn't an issue with
> modversioning as the only symbols that would be used there wouldn't be
> static.
>
> Sami, what was the exact userspace issue with CONFIG_LTO_CLANG and these
> long symbols?

The issue with LTO wasn't symbol length. IIRC the compiler renaming
symbols with ThinLTO caused issues for folks using dynamic kprobes,
and I seem to recall it also breaking systrace in Android, at which
point we decided to strip the postfix in kallsyms to avoid breaking
anything else.

Sami