Re: [PATCH v5 15/24] arm64: vdso: Enable the vdsocheck tool

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] R_AARCH64_JUMP26 is missing from the list of allowed AArch64 vDSO relocations, which breaks the build when the compiler optimizes tail calls.
- [Low] The Rust vdsocheck tool unconditionally rejects all relocation sections in the linked DSO, removing the known workaround for harmless R_*_NONE relocations.
--

commit de060cbc8fa252ca9eccafa1af109831e25d164f
Author: Thomas Weißschuh <thomas.weissschuh@linutronix.de>

arm64: vdso: Enable the vdsocheck tool

The vdsocheck tool validates the object files and final .so library.
It can detect if the compiler created relocations which are incompatible
with the vDSO which need to be worked around.

> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 11e733b6a3cf3..f0dd557b16032 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -256,6 +256,7 @@ config ARM64
>  	select TRACE_IRQFLAGS_NMI_SUPPORT
>  	select HAVE_SOFTIRQ_ON_OWN_STACK
>  	select USER_STACKTRACE_SUPPORT
> +	select VDSO_CHECK

[Severity: Low]
Does enabling this checker break builds on toolchains that emit unneeded
R_*_NONE dynamic relocations?

In the legacy shell script workaround in lib/vdso/Makefile.include,
grep -v _NONE was used to safely ignore harmless empty dynamic relocations
generated by some older GNU ld ports.

In the Rust vdsocheck tool, validate_linked_dso() now unconditionally
rejects any relocation section:

lib/vdso/check/vdsocheck.rs:validate_linked_dso() {
    for section in file.sections()? {
        ...
        match section {
            elf::Section::Rel(_) | elf::Section::Rela(_) => {
                return Err(ValidationError::UnexpectedSection(section))
            }
            _ => {}
        }
    }
}

Because it does not iterate the section entries to filter or ignore _NONE
relocations, will this unconditionally return UnexpectedSection and break
builds relying on the previous workaround?

>  	select VDSO_GETRANDOM
>  	select VMAP_STACK
>  	help

[ ... ]

> diff --git a/lib/vdso/check/vdsocheck.rs b/lib/vdso/check/vdsocheck.rs
> index fb88ef0be09d9..e45a1fbc6829c 100644
> --- a/lib/vdso/check/vdsocheck.rs
> +++ b/lib/vdso/check/vdsocheck.rs
> @@ -57,6 +57,18 @@ fn allowed_relocations_for_machine(machine: u16) -> Option<AllowedRelocations<'s
>              ..Default::default()
>          }
>          .into(),
> +        bindings::EM_AARCH64 => AllowedRelocations {
> +            in_object_file: &[
> +                bindings::R_AARCH64_PREL64,
> +                bindings::R_AARCH64_PREL32,
> +                bindings::R_AARCH64_PREL16,
> +                bindings::R_AARCH64_LD_PREL_LO19,
> +                bindings::R_AARCH64_ADR_PREL_LO21,
> +                bindings::R_AARCH64_CALL26,
> +            ],

[Severity: Low]
Will this break the build when the compiler applies tail-call optimizations?

If the compiler optimizes tail calls in a vDSO function, it emits a B
instruction which generates an R_AARCH64_JUMP26 relocation. Since
bindings::R_AARCH64_JUMP26 is omitted from this list of allowed relocations,
validate_object_file() will encounter it, fail the in_object_file.contains()
check, and return InvalidRelocation, aborting the build.

> +            ..Default::default()
> +        }
> +        .into(),
>          _ => None,
>      }
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260908-vdso-absolute-reloc-v5-0-3a93791af1cf@linutronix.de?part=15