All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Borkmann <daniel@iogearbox.net>
To: Tony Ambardar <tony.ambardar@gmail.com>,
	Alexei Starovoitov <ast@kernel.org>
Cc: netdev@vger.kernel.org, bpf@vger.kernel.org,
	linux-arch@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH bpf v1 0/3] fix BTF usage on embedded systems
Date: Mon, 21 Sep 2020 22:52:42 +0200	[thread overview]
Message-ID: <898b6212-0521-6a37-c982-7bb2ef31264f@iogearbox.net> (raw)
In-Reply-To: <cover.1600417359.git.Tony.Ambardar@gmail.com>

On 9/20/20 7:01 AM, Tony Ambardar wrote:
> 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(-)
> 

Applied, thanks!

      parent reply	other threads:[~2020-09-21 20:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-20  5:01 [PATCH bpf v1 0/3] fix BTF usage on embedded systems Tony Ambardar
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 [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=898b6212-0521-6a37-c982-7bb2ef31264f@iogearbox.net \
    --to=daniel@iogearbox.net \
    --cc=arnd@arndb.de \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=tony.ambardar@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.