linux-kernel - Re: [PATCH] kallsyms: strip LTO suffixes from static functions

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]

Date:   Mon, 28 Jun 2021 11:20:41 -0700
From:   Nick Desaulniers <ndesaulniers@...gle.com>
To:     Fangrui Song <maskray@...gle.com>
Cc:     Kees Cook <keescook@...omium.org>, "KE . LI" <like1@...o.com>,
        Nathan Chancellor <nathan@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Miroslav Benes <mbenes@...e.cz>,
        "Gustavo A. R. Silva" <gustavoars@...nel.org>,
        Stephen Boyd <swboyd@...omium.org>,
        Sami Tolvanen <samitolvanen@...gle.com>,
        Joe Perches <joe@...ches.com>, linux-kernel@...r.kernel.org,
        clang-built-linux@...glegroups.com
Subject: Re: [PATCH] kallsyms: strip LTO suffixes from static functions

On Mon, Jun 28, 2021 at 10:54 AM Nick Desaulniers
<ndesaulniers@...gle.com> wrote:
>
> On Tue, Jun 22, 2021 at 1:18 PM Fangrui Song <maskray@...gle.com> wrote:
> >
> > On 2021-06-22, 'Nick Desaulniers' via Clang Built Linux wrote:
> > >+/*
> > >+ * LLVM mangles static functions for full LTO so that two static functions with
> > >+ * the same identifier do not collide when all code is combined into one
> > >+ * module. The scheme used converts references to foo into
> > >+ * foo.llvm.974640843467629774, for example. This can break hooking of static
> > >+ * functions with kprobes.
> > >+ */
> >
> > The comment should say ThinLTO instead.
> >
> > The .llvm.123 suffix is for global scope promotion for local linkage
> > symbols. The scheme is ThinLTO specific. This ensures that a local
>
> Oh, boy. Indeed.  I had identified the mangling coming from
> getGlobalNameForLocal(), but looking at the call chain now I see:
>
> FunctionImportGlobalProcessing::processGlobalForThinLTO()
> -> FunctionImportGlobalProcessing::getPromotedName()
>   -> ModuleSummaryIndex::getGlobalNameForLocal()
>
> I'm not sure then how I figured it was specific to full LTO.
>
> Android recently switched from thin LTO to full LTO, which is what I
> assumed was the cause of the bug report. Rereading our internal bug
> report, it was tested against a prior version that did the symbol
> truncation for thinLTO. I then assumed this was full LTO specific for
> whatever reason, and modified the patch to only apply to full LTO.  I
> see via the above call chain that this patch is not correct.  Let me
> send my original patch as a v2. b/189560201 if you're interested.

I can even see the .llvm.<number> symbol names via `llvm-nm` on
vmlinux for thinLTO builds. No such symbols exist for full LTO.

-- 
Thanks,
~Nick Desaulniers