From: Tony Ambardar <tony.ambardar@gmail.com>
To: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>
Cc: Tony Ambardar <Tony.Ambardar@gmail.com>,
netdev@vger.kernel.org, bpf@vger.kernel.org,
linux-arch@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>
Subject: [PATCH bpf v1 0/3] fix BTF usage on embedded systems
Date: Sat, 19 Sep 2020 22:01:32 -0700 [thread overview]
Message-ID: <cover.1600417359.git.Tony.Ambardar@gmail.com> (raw)
Hello,
I've been experimenting with BPF and BTF on small, emebedded platforms
requiring cross-compilation to varying archs, word-sizes, and endianness.
These environments are not the most common for the majority of eBPF users,
and have exposed multiple problems with basic functionality. This patch
series addresses some of these issues.
Enabling BTF support in the kernel can sometimes result in sysfs export
of /sys/kernel/btf/vmlinux as a zero-length file, which is still readable
and seen to leak non-zero kernel data. Patch #1 adds a sanity-check to
avoid this situation.
Small systems commonly enable LD_DEAD_CODE_DATA_ELIMINATION, which causes
the .BTF section data to be incorrectly removed and can trigger the problem
above. Patch #2 preserves the BTF data.
Even if BTF data is generated and embedded in the kernel, it may be encoded
as non-native endianness due to another bug [1] currently being worked on.
Patch #3 lets bpftool recognize the wrong BTF endianness rather than output
a confusing/misleading ELF header error message.
Patches #1 and #2 were first developed for Linux 5.4.x and should be
backported if possible. Feedback and suggestions for improvement are
welcome!
Thanks,
Tony
[1] https://lore.kernel.org/bpf/CAPGftE8ipAacAnm9xMHFabXCL-XrCXGmOsX-Nsjvz9wnh3Zx-w@mail.gmail.com/
Tony Ambardar (3):
bpf: fix sysfs export of empty BTF section
bpf: prevent .BTF section elimination
libbpf: fix native endian assumption when parsing BTF
include/asm-generic/vmlinux.lds.h | 2 +-
kernel/bpf/sysfs_btf.c | 6 +++---
tools/lib/bpf/btf.c | 6 ++++++
3 files changed, 10 insertions(+), 4 deletions(-)
--
2.25.1
next reply other threads:[~2020-09-20 5:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-20 5:01 Tony Ambardar [this message]
2020-09-20 5:01 ` [PATCH bpf v1 1/3] bpf: fix sysfs export of empty BTF section Tony Ambardar
2020-09-21 15:44 ` John Fastabend
2020-09-21 19:21 ` Andrii Nakryiko
2020-09-20 5:01 ` [PATCH bpf v1 2/3] bpf: prevent .BTF section elimination Tony Ambardar
2020-09-21 15:45 ` John Fastabend
2020-09-20 5:01 ` [PATCH bpf v1 3/3] libbpf: fix native endian assumption when parsing BTF Tony Ambardar
2020-09-21 15:46 ` John Fastabend
2020-09-21 19:24 ` [PATCH bpf v1 0/3] fix BTF usage on embedded systems Andrii Nakryiko
2020-09-21 20:52 ` Daniel Borkmann
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=cover.1600417359.git.Tony.Ambardar@gmail.com \
--to=tony.ambardar@gmail.com \
--cc=arnd@arndb.de \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=linux-arch@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).