kbuild: Avoid weak external linkage where possible

From: Ard Biesheuvel <[email protected]>

kallsyms is a directory of all the symbols in the vmlinux binary, and so creating it is somewhat of a chicken-and-egg problem, as its non-zero size affects the layout of the binary, and therefore the values of the symbols.

For this reason, the kernel is linked more than once, and the first pass does not include any kallsyms data at all. For the linker to accept this, the symbol declarations describing the kallsyms metadata are emitted as having weak linkage, so they can remain unsatisfied. During the subsequent passes, the weak references are satisfied by the kallsyms metadata that was constructed based on information gathered from the preceding passes.

Weak references lead to somewhat worse codegen, because taking their address may need to produce NULL (if the reference was unsatisfied), and this is not usually supported by RIP or PC relative symbol references.

Given that these references are ultimately always satisfied in the final link, let's drop the weak annotation, and instead, provide fallback definitions in the linker script that are only emitted if an unsatisfied reference exists.

While at it, drop the FRV specific annotation that these symbols reside in .rodata - FRV is long gone.

Tested-by Nick Desaulniers <[email protected]> # Boot

Reviewed-by Nick Desaulniers <[email protected]>

Reviewed-by Kees Cook <[email protected]>

Acked-by Arnd Bergmann <[email protected]>

Link https://lkml.kernel.org/r/20230504174320.3930345-1-ardb%40kernel.org open here

Signed-off-by Ard Biesheuvel <[email protected]>

---

 include/asm-generic/vmlinux.lds.h | 19 +++++++++++++
 kernel/kallsyms.c                 |  6 ----
 kernel/kallsyms_internal.h        | 30 ++++++++------------
 3 files changed, 31 insertions(+), 24 deletions(-)

include/asm-generic/vmlinux.lds.h +19 -0

index f7749d0f2562..e8449be62058 100644
@@ -448,11 +448,30 @@
 #endif
 #endif
 
+/*
+ * Some symbol definitions will not exist yet during the first pass of the
+ * link, but are guaranteed to exist in the final link. Provide preliminary
+ * definitions that will be superseded in the final link to avoid having to
+ * rely on weak external linkage, which requires a GOT when used in position
+ * independent code.
+ */
+#define PRELIMINARY_SYMBOL_DEFINITIONS                                 \
+       PROVIDE(kallsyms_addresses = .);                                \
+       PROVIDE(kallsyms_offsets = .);                                  \
+       PROVIDE(kallsyms_names = .);                                    \
+       PROVIDE(kallsyms_num_syms = .);                                 \
+       PROVIDE(kallsyms_relative_base = .);                            \
+       PROVIDE(kallsyms_token_table = .);                              \
+       PROVIDE(kallsyms_token_index = .);                              \
+       PROVIDE(kallsyms_markers = .);                                  \
+       PROVIDE(kallsyms_seqs_of_names = .);
+
 /*
  * Read only Data
  */
 #define RO_DATA(align)                                                 \
        . = ALIGN((align));                                             \
+       PRELIMINARY_SYMBOL_DEFINITIONS                                  \
        .rodata           : AT(ADDR(.rodata) - LOAD_OFFSET) {           \
                __start_rodata = .;                                     \
                *(.rodata) *(.rodata.*)                                 \

kernel/kallsyms.c +0 -6

index 18edd57b5fe8..22ea19a36e6e 100644
@@ -325,12 +325,6 @@ static unsigned long get_symbol_pos(unsigned long addr,
        unsigned long symbol_start = 0, symbol_end = 0;
        unsigned long i, low, high, mid;
 
-       /* This kernel should never had been booted. */
-       if (!IS_ENABLED(CONFIG_KALLSYMS_BASE_RELATIVE))
-               BUG_ON(!kallsyms_addresses);
-       else
-               BUG_ON(!kallsyms_offsets);
-
        /* Do a binary search on the sorted kallsyms_addresses array. */
        low = 0;
        high = kallsyms_num_syms;

kernel/kallsyms_internal.h +12 -19

index 27fabdcc40f5..85480274fc8f 100644
@@ -5,27 +5,21 @@
 #include <linux/types.h>
 
 /*
- * These will be re-linked against their real values
- * during the second link stage.
+ * These will be re-linked against their real values during the second link
+ * stage. Preliminary values must be provided in the linker script using the
+ * PROVIDE() directive so that the first link stage can complete successfully.
  */
-extern const unsigned long kallsyms_addresses[] __weak;
-extern const int kallsyms_offsets[] __weak;
-extern const u8 kallsyms_names[] __weak;
+extern const unsigned long kallsyms_addresses[];
+extern const int kallsyms_offsets[];
+extern const u8 kallsyms_names[];
 
-/*
- * Tell the compiler that the count isn't in the small data section if the arch
- * has one (eg: FRV).
- */
-extern const unsigned int kallsyms_num_syms
-__section(".rodata") __attribute__((weak));
-
-extern const unsigned long kallsyms_relative_base
-__section(".rodata") __attribute__((weak));
+extern const unsigned int kallsyms_num_syms;
+extern const unsigned long kallsyms_relative_base;
 
-extern const char kallsyms_token_table[] __weak;
-extern const u16 kallsyms_token_index[] __weak;
+extern const char kallsyms_token_table[];
+extern const u16 kallsyms_token_index[];
 
-extern const unsigned int kallsyms_markers[] __weak;
-extern const u8 kallsyms_seqs_of_names[] __weak;
+extern const unsigned int kallsyms_markers[];
+extern const u8 kallsyms_seqs_of_names[];
 
 #endif // LINUX_KALLSYMS_INTERNAL_H_
--

2.44.0.683.g7961c838ac-goog

From: Ard Biesheuvel <[email protected]>

Weak references are references that are permitted to remain unsatisfied in the final link. This means they cannot be implemented using place relative relocations, resulting in GOT entries when using position independent code generation.

The notes section should always exist, so the weak annotations can be omitted.

Acked-by Arnd Bergmann <[email protected]>

Signed-off-by Ard Biesheuvel <[email protected]>

---
 kernel/ksysfs.c | 4 ++--
 lib/buildid.c   | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

kernel/ksysfs.c +2 -2

index 495b69a71a5d..07fb5987b42b 100644
@@ -228,8 +228,8 @@ KERNEL_ATTR_RW(rcu_normal);
 /*
  * Make /sys/kernel/notes give the raw contents of our kernel .notes section.
  */
-extern const void __start_notes __weak;
-extern const void __stop_notes __weak;
+extern const void __start_notes;
+extern const void __stop_notes;
 #define        notes_size (&__stop_notes - &__start_notes)
 
 static ssize_t notes_read(struct file *filp, struct kobject *kobj,

lib/buildid.c +2 -3

index 898301b49eb6..7954dd92e36c 100644
@@ -182,8 +182,8 @@ unsigned char vmlinux_build_id[BUILD_ID_SIZE_MAX] __ro_after_init;
  */
 void __init init_vmlinux_build_id(void)
 {
-       extern const void __start_notes __weak;
-       extern const void __stop_notes __weak;
+       extern const void __start_notes;
+       extern const void __stop_notes;
        unsigned int size = &__stop_notes - &__start_notes;
 
        build_id_parse_buf(&__start_notes, vmlinux_build_id, size);
--

2.44.0.683.g7961c838ac-goog

Hello:

This series was applied to bpf/bpf-next.git (master) by Daniel Borkmann <[email protected]>:

Quoted 6 lines · On Mon, 15 Apr 2024 18:20:42 +0200 you wrote:

From: Ard Biesheuvel <[email protected]>

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.

Quoted 6 lines

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

Quoted 20 lines · On Tue, 16 Apr 2024 at 16:40, <[email protected]> wrote:

Hello:

This series was applied to bpf/bpf-next.git (master) by Daniel Borkmann <[email protected]>:

Quoted 6 lines · On Mon, 15 Apr 2024 18:20:42 +0200 you wrote:

From: Ard Biesheuvel <[email protected]>

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.

Quoted 6 lines

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.

[...]

Quoted 8 lines

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?

Quoted 32 lines · Ard Biesheuvel

Quoted 20 lines · On Tue, 16 Apr 2024 at 16:40, <[email protected]> wrote:

Hello:

This series was applied to bpf/bpf-next.git (master) by Daniel Borkmann <[email protected]>:

Quoted 6 lines · On Mon, 15 Apr 2024 18:20:42 +0200 you wrote:

From: Ard Biesheuvel <[email protected]>

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.

Quoted 6 lines

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.

[...]

Quoted 8 lines

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

Quoted 4 lines

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.

With PROVIDE() added, we will never detect it at a build time.

Do you want me to pick up 1/3?

Quoted 45 lines · Masahiro Yamada

Quoted 32 lines · Ard Biesheuvel

Quoted 20 lines · On Tue, 16 Apr 2024 at 16:40, <[email protected]> wrote:

Hello:

This series was applied to bpf/bpf-next.git (master) by Daniel Borkmann <[email protected]>:

Quoted 6 lines · On Mon, 15 Apr 2024 18:20:42 +0200 you wrote:

From: Ard Biesheuvel <[email protected]>

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.

Quoted 6 lines

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.

[...]

Quoted 8 lines

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

Quoted 4 lines

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.

Quoted 4 lines

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.

Quoted 6 lines

With PROVIDE() added, we will never detect it at a build time.

Do you want me to pick up 1/3?

???

Quoted 47 lines · Ard Biesheuvel

Quoted 45 lines · Masahiro Yamada

Quoted 32 lines · Ard Biesheuvel

Quoted 20 lines · On Tue, 16 Apr 2024 at 16:40, <[email protected]> wrote:

Hello:

This series was applied to bpf/bpf-next.git (master) by Daniel Borkmann <[email protected]>:

Quoted 6 lines · On Mon, 15 Apr 2024 18:20:42 +0200 you wrote:

From: Ard Biesheuvel <[email protected]>

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.

Quoted 6 lines

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.

[...]

Quoted 8 lines

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

Quoted 4 lines

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.

Quoted 6 lines

Quoted 4 lines

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)

Quoted 57 lines · Masahiro Yamada

Quoted 47 lines · Ard Biesheuvel

Quoted 45 lines · Masahiro Yamada

Quoted 32 lines · Ard Biesheuvel

Quoted 20 lines · On Tue, 16 Apr 2024 at 16:40, <[email protected]> wrote:

Hello:

This series was applied to bpf/bpf-next.git (master) by Daniel Borkmann <[email protected]>:

Quoted 6 lines · On Mon, 15 Apr 2024 18:20:42 +0200 you wrote:

From: Ard Biesheuvel <[email protected]>

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.

Quoted 6 lines

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.

[...]

Quoted 8 lines

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

Quoted 4 lines

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.

Quoted 6 lines

Quoted 4 lines

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.

Quoted 7 lines

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.

Quoted 68 lines · Ard Biesheuvel

Quoted 64 lines · Masahiro Yamada

Quoted 47 lines · Ard Biesheuvel

Quoted 45 lines · Masahiro Yamada

Quoted 32 lines · Ard Biesheuvel

Quoted 20 lines · On Tue, 16 Apr 2024 at 16:40, <[email protected]> wrote:

Hello:

This series was applied to bpf/bpf-next.git (master) by Daniel Borkmann <[email protected]>:

Quoted 6 lines · On Mon, 15 Apr 2024 18:20:42 +0200 you wrote:

From: Ard Biesheuvel <[email protected]>

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.

Quoted 6 lines

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.

[...]

Quoted 8 lines

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

Quoted 4 lines

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.

Quoted 6 lines

Quoted 4 lines

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)

Quoted 6 lines

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.

Btw those references in kernel/vmcore_info.c are guarded by #ifdef CONFIG_KALLSYMS=y too.