BPF List
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "HyeongJun An" <sammiee5311@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf 2/2] selftests/bpf: Test linker rejects out-of-range relocation offset
Date: Sun, 14 Jun 2026 05:53:15 +0000	[thread overview]
Message-ID: <20260614055315.A09871F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260614053927.160566-3-sammiee5311@gmail.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The dynamically generated ELF file hardcodes little-endian byte order (`ELFDATA2LSB`), which breaks the test on big-endian architectures.
- [Low] Build failure due to undeclared `R_BPF_64_64` (and potentially `EM_BPF`) on systems with older standard headers.
--

commit ea0de1dc0625c22a9ceaf6b346bc7dcde8b649da
Author: HyeongJun An <sammiee5311@gmail.com>

selftests/bpf: Test linker rejects out-of-range relocation offset
    
Add regression coverage for libbpf static linker relocation offset checks.
Build a minimal ET_REL/EM_BPF object in memory with a 16-byte executable
section and one relocation against that section.

> diff --git a/tools/testing/selftests/bpf/prog_tests/libbpf_linker.c b/tools/testing/selftests/bpf/prog_tests/libbpf_linker.c
> new file mode 100644
> index 0000000000000..e7bec24343498
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/libbpf_linker.c

[ ... ]

> +	ehdr = obj.buf;
> +	memcpy(ehdr->e_ident, ELFMAG, SELFMAG);
> +	ehdr->e_ident[EI_CLASS] = ELFCLASS64;
> +	ehdr->e_ident[EI_DATA] = ELFDATA2LSB;

[Severity: Medium]
Does hardcoding ELFDATA2LSB here break the test on big-endian architectures?

Since the ELF header and structures are initialized using native host
byte-order C struct assignments (like ehdr->e_type = ET_REL), libelf
will see ELFDATA2LSB on big-endian systems (like s390x) and incorrectly
byte-swap the already native big-endian fields. This could cause the linker
to reject the ELF file with -EOPNOTSUPP.

Should EI_DATA be set dynamically to match the host's byte order?

> +	ehdr->e_ident[EI_VERSION] = EV_CURRENT;
> +	ehdr->e_type = ET_REL;
> +	ehdr->e_machine = EM_BPF;

[Severity: Low]
Could this cause a build failure on systems with older standard headers?
EM_BPF might be undeclared on extremely old systems.

> +	ehdr->e_version = EV_CURRENT;
> +	ehdr->e_ehsize = sizeof(*ehdr);
> +	ehdr->e_shoff = shdr_off;
> +	ehdr->e_shentsize = sizeof(*shdr);
> +	ehdr->e_shnum = SEC_CNT;
> +	ehdr->e_shstrndx = SEC_SHSTRTAB;
> +
> +	memcpy(obj.buf + text_off, insns, sizeof(insns));
> +
> +	rel = obj.buf + rel_off;
> +	rel->r_offset = relo_off;
> +	rel->r_info = ELF64_R_INFO(1, R_BPF_64_64);

[Severity: Low]
Will this fail to compile on systems with older standard headers?

R_BPF_64_64 was only added in glibc 2.32 (August 2020). On systems with older
headers, such as Ubuntu 20.04 commonly used in CI environments, R_BPF_64_64
is undeclared.

libbpf works around this by providing fallback definitions in
libbpf_internal.h, but libbpf_linker.c doesn't include it. Could we add a
fallback definition for R_BPF_64_64 in this test to ensure it builds on older
environments?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260614053927.160566-1-sammiee5311@gmail.com?part=2

      reply	other threads:[~2026-06-14  5:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-14  5:39 [PATCH bpf 0/2] libbpf: Reject out-of-range linker relocation offsets HyeongJun An
2026-06-14  5:39 ` [PATCH bpf 1/2] " HyeongJun An
2026-06-14  7:50   ` sashiko-bot
2026-06-14  5:39 ` [PATCH bpf 2/2] selftests/bpf: Test linker rejects out-of-range relocation offset HyeongJun An
2026-06-14  5:53   ` sashiko-bot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260614055315.A09871F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=sammiee5311@gmail.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox