Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\))
Subject: Re: [PATCH v2] x86/lib: Do not use local symbols with
 SYM_CODE_START_LOCAL()
From:   Nadav Amit <nadav.amit@gmail.com>
In-Reply-To: <e6cd1909-2776-28d2-ccc0-4b3d2d09e9ce@intel.com>
Date:   Fri, 26 May 2023 14:55:21 -0700
Cc:     Borislav Petkov <bp@alien8.de>, Jiri Slaby <jirislaby@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        X86 ML <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <49861038-B8CA-4CDD-BD44-73066FF453F3@gmail.com>
References: <20230525184244.2311-1-namit@vmware.com>
 <38e24fd4-9213-229d-9919-7ae3bfb113bb@intel.com>
 <24E47178-C177-425F-A8EF-CFFAE22597D4@gmail.com>
 <20230526155336.GAZHDWAFi1FRqq83TP@nazgul.local>
 <0F07EEDB-8A3F-4224-9FF1-43A5300B1B8B@gmail.com>
 <20230526204559.GAZHEahxxnQaHhSUul@nazgul.local>
 <D63AB9E6-BA52-4E24-B8EF-C7B9DB1595CC@gmail.com>
 <e6cd1909-2776-28d2-ccc0-4b3d2d09e9ce@intel.com>
To:     Dave Hansen <dave.hansen@intel.com>
Precedence: bulk


> On May 26, 2023, at 2:17 PM, Dave Hansen <dave.hansen@intel.com> =
wrote:
>=20
> On 5/26/23 14:10, Nadav Amit wrote:
>>>> 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:
>>>=20
>>> 105185: ffffffff81b89330    17 NOTYPE  LOCAL  DEFAULT    1 =
bad_get_user_clac
>>>=20
>>> 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.
>>=20
>> I personally work on code instrumentation and this makes my life hard =
for
>> no good reason.
>>=20
>> [ Perhaps the question should go the other way around: why addresses =
of
>> code in these functions should not be mapped to any symbol? ]
>=20
> Nadav, is there a chance you could give us a real-life example of how
> this affects you as an end user?  What's a specific tool that you were
> using or a specific problem that you were trying to solve where these
> local symbols caused a problem?  How would the global symbol have =
helped?
>=20
> I can certainly _imagine_ some, but I'm curious what you saw that
> prompted you to send this patch.

So my tool takes a branch trace and then simulates the code execution.
As a preparatory step I need to disassemble the code, yet as I do not
know where the symbol starts and its size, I can only disassemble one
instruction at a time. [ I prefer to disassemble the whole symbol at =
once
not just for performance, but also to figure out if it includes some
instructions that my simulator does not know to simulate correctly. ]

In addition, as I read the code from kcore and the binary keeps =
changing,
I want to assume that if I do not find an address in the symbol table =
[*]
then it means this is some dynamically generated code that is no longer
available through kcore (eBPF, ftrace, etc.).

These are only 2 things that break to one extent or another. I can
have workarounds for them (I already do). I just see no reason to
treat these two symbols differently.

I would also note that I can think of many many additional reasons to
have each piece of code mapped back to a symbol (besides debuggers,
tracers, etc.) For instance, security monitoring tools should prefer to
be able to check what code is running in the kernel.

I seriously see no downside here and only benefit in consistency and
usability. I have no hidden agenda if for some reason you suspect that
I do. I don=E2=80=99t want to start talking too much about the tool I =
work on,
as I am afraid it is off-topic, but I hope to open source it soon.=20

--

[*] I know kallsyms does not give sizes, but I make some reasonable
assumptions and augment kallsyms with the symbols from the binary.=