linux-kernel - Re: [PATCH v4 0/3] kbuild: Avoid weak external linkage where possible

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: <CAMj1kXEbXfsNarFMbDC-Dzk6H9X9C4Ax2pWPSZhmt93mV4_Q2w@mail.gmail.com>
Date: Sat, 20 Apr 2024 15:56:31 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: Masahiro Yamada <masahiroy@...nel.org>
Cc: patchwork-bot+netdevbpf@...nel.org, Ard Biesheuvel <ardb+git@...gle.com>, 
	linux-kernel@...r.kernel.org, arnd@...db.de, martin.lau@...ux.dev, 
	linux-arch@...r.kernel.org, linux-kbuild@...r.kernel.org, bpf@...r.kernel.org, 
	andrii@...nel.org, olsajiri@...il.com
Subject: Re: [PATCH v4 0/3] kbuild: Avoid weak external linkage where possible

On Sat, 20 Apr 2024 at 15:42, Masahiro Yamada <masahiroy@...nel.org> wrote:
>
> On Sat, Apr 20, 2024 at 9:35 PM Ard Biesheuvel <ardb@...nel.org> wrote:
> >
> > On Sat, 20 Apr 2024 at 14:32, Masahiro Yamada <masahiroy@...nel.org> wrote:
> > >
> > > On Fri, Apr 19, 2024 at 4:57 PM Ard Biesheuvel <ardb@...nel.org> wrote:
> > > >
> > > > On Tue, 16 Apr 2024 at 16:40, <patchwork-bot+netdevbpf@...nel.org> wrote:
> > > > >
> > > > > Hello:
> > > > >
> > > > > This series was applied to bpf/bpf-next.git (master)
> > > > > by Daniel Borkmann <daniel@...earbox.net>:
> > > > >
> > > > > On Mon, 15 Apr 2024 18:20:42 +0200 you wrote:
> > > > > > From: Ard Biesheuvel <ardb@...nel.org>
> > > > > >
> > > > > > Weak external linkage is intended for cases where a symbol reference
> > > > > > can remain unsatisfied in the final link. Taking the address of such a
> > > > > > symbol should yield NULL if the reference was not satisfied.
> > > > > >
> > > > > > Given that ordinary RIP or PC relative references cannot produce NULL,
> > > > > > some kind of indirection is always needed in such cases, and in position
> > > > > > independent code, this results in a GOT entry. In ordinary code, it is
> > > > > > arch specific but amounts to the same thing.
> > > > > >
> > > > > > [...]
> > > > >
> > > > > Here is the summary with links:
> > > > >   - [v4,1/3] kallsyms: Avoid weak references for kallsyms symbols
> > > > >     (no matching commit)
> > > > >   - [v4,2/3] vmlinux: Avoid weak reference to notes section
> > > > >     (no matching commit)
> > > > >   - [v4,3/3] btf: Avoid weak external references
> > > > >     https://git.kernel.org/bpf/bpf-next/c/fc5eb4a84e4c
> > > > >
> > > >
> > > >
> > > > Thanks.
> > > >
> > > > Masahiro, could you pick up patches #1 and #2 please?
> > > >
> > >
> > >
> > > I do not like PROVIDE() because it potentially shifts
> > > a build error (i.e. link error) into
> > > a run-time error, which is usually more difficult to debug
> > > than build error.
> > >
> > > If someone references the kallsyms_* symbols
> > > when CONFIG_KALLSYMS=n, it is likely a mistake.
> > > In general, it should be reported as a link error.
> > >
> >
> > OK, so the PROVIDE() should be conditional on CONFIG_KALLSYM=y. I can fix that.
>
>
> You may need to take care of the dependency
> between CONFIG_KALLSYMS and CONFIG_VMCORE_INFO
> because kernel/vmcore_info.c has references
> to the kallsyms_* symbols.
>
> (I am still not a big fan of PROVIDE() though)
>


OK, how about we use weak definitions (as opposed to weak references)
in kernel/kallsyms.c, which will get superseded by the actual ones in
the second linker pass.

The only difference is that we will use some space in the binary for
the weak definitions that are never used in the final build.