linux-kernel - Re: [PATCH v2] x86/lib: Do not use local symbols with SYM_CODE_START

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: <D63AB9E6-BA52-4E24-B8EF-C7B9DB1595CC@gmail.com>
Date:   Fri, 26 May 2023 14:10:47 -0700
From:   Nadav Amit <nadav.amit@...il.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Dave Hansen <dave.hansen@...el.com>,
        Jiri Slaby <jirislaby@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        X86 ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] x86/lib: Do not use local symbols with
 SYM_CODE_START_LOCAL()

> On May 26, 2023, at 1:45 PM, Borislav Petkov <bp@...en8.de> wrote:
> 
> On Fri, May 26, 2023 at 10:29:29AM -0700, Nadav Amit wrote:
>> Can you give me some examples for code whose address cannot be mapped
>> back to a symbol?
> 
> No, this is not what I'm talking about.
> 
> I'm talking about all the local labels the compiler uses. For example:
> 
> $ make kernel/sched/core.s
> $ grep -E "^\.L" kernel/sched/core.s | wc -l
> 2799
> 
> All those local labels are not in the symbol table (get discarded) and
> the addresses they represent are shown as belonging to the containing
> function.

Right. But the symbols I mentioned are not contained in any other symbol.
If you run gdb and try to disasm this bad_get_user_clac (its address),
you’d currently get "No function contains specified address”.

That what makes these 2 symbols different than the others.

> 
>> I did not ask to make them global. Just to keep them as local after
>> linkage in the executable, like all other functions in the kernel.
> 
> Ok, not global. But local and present in the symbol table:
> 
> 105185: ffffffff81b89330    17 NOTYPE  LOCAL  DEFAULT    1 bad_get_user_clac
> 
> And again, this helps how exactly?

Allowing debuggers, tracers, disassemblers and instrumentation tools to
work the same way they work as they work with any other piece of code in
the kernel.

I personally work on code instrumentation and this makes my life hard for
no good reason.

[ Perhaps the question should go the other way around: why addresses of
code in these functions should not be mapped to any symbol? ]