From: Daniel Borkmann <daniel@iogearbox.net>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>,
Rafael David Tinoco <rafaeldtinoco@ubuntu.com>
Cc: bpf <bpf@vger.kernel.org>
Subject: Re: [PATCH] libbpf: allow bpf object kern_version to be overridden
Date: Thu, 18 Mar 2021 21:56:27 +0100 [thread overview]
Message-ID: <318f936b-2f7c-7d4a-cb40-baf673bd6c9e@iogearbox.net> (raw)
In-Reply-To: <CAEf4BzZBy+H_ZHTf+fErB2-aMpJr+JSAgCYwvtWbG7dT3=97Cw@mail.gmail.com>
On 3/18/21 8:46 PM, Andrii Nakryiko wrote:
> On Thu, Mar 18, 2021 at 12:31 PM Rafael David Tinoco
> <rafaeldtinoco@ubuntu.com> wrote:
>>
>> Unfortunately some distros don't have their accurate kernel version
>> defined correctly in version.h due to long term support decisions. This
>> makes LINUX_VERSION_CODE to be defined as the original upstream version
>> in header, while the running in-kernel version is different.
>>
>> Older kernels might still check kern_version during bpf_prog_load(),
>> making it impossible to load a program that could still be portable.
>> This patch allows one to override bpf objects kern_version attributes,
>> so program can bypass this in-kernel check during load.
>>
>> Example:
>>
>> A kernel 4.15.0-129.132, for example, might have 4.15.18 version defined
>> in its headers, which is the kernel it is based on, but have a 4.15.0
>> version defined within the kernel due to other factors.
>>
>> $ export LIBBPF_KERN_VERSION=4.15.18
>> $ sudo -E ./portablebpf -v
>> ...
>> libbpf: bpf object: kernel_version enforced by env variable: 266002
>> ...
>>
>> This will also help portable binaries within similar older kernels, as
>> long as they have their BTF data converted from DWARVES (for example).
>>
>> Signed-off-by: Rafael David Tinoco <rafaeldtinoco@ubuntu.com>
>> ---
>
> Libbpf currently provides a way to specify custom kernel version using
> a special "version" ELF section:
>
> int _version SEC("version") = 123;
>
> But it seems like you would want to set it at runtime, so this
> compile-time approach might be problematic. But instead of hijacking
> get_kernel_version(), it's better to add a simple setter counterpart
> to bpf_object__kversion() that would just override obj->kern_version.
+1, agree, setter makes sense for old kernels, so the loader app can set/
retrieve from wherever it's needed. In addition, couldn't you also backport
the old commit that ignores the kern_version from kernel side (won't help
existing users, but at least might simplify things once they start upgrade)?
Thanks,
Daniel
next prev parent reply other threads:[~2021-03-18 20:57 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-18 6:25 [RFC][PATCH] libbpf: support kprobe/kretprobe events in legacy environments Rafael David Tinoco
2021-03-18 19:31 ` [PATCH] libbpf: allow bpf object kern_version to be overridden Rafael David Tinoco
2021-03-18 19:46 ` Andrii Nakryiko
2021-03-18 20:56 ` Daniel Borkmann [this message]
2021-03-19 4:38 ` Rafael David Tinoco
2021-03-19 4:51 ` [RFC][PATCH] libbpf: support kprobe/kretprobe events in legacy environments Andrii Nakryiko
2021-03-22 18:04 ` [PATCH v2 bpf-next][RFC] libbpf: introduce legacy kprobe events support Rafael David Tinoco
2021-03-22 18:25 ` Rafael David Tinoco
2021-03-26 20:50 ` Andrii Nakryiko
2021-04-07 4:49 ` Rafael David Tinoco
2021-04-07 22:33 ` Andrii Nakryiko
2021-04-08 23:59 ` John Fastabend
2021-04-14 14:30 ` Rafael David Tinoco
2021-04-14 20:06 ` Rafael David Tinoco
2021-04-14 23:23 ` Andrii Nakryiko
2021-04-15 5:53 ` Rafael David Tinoco
2021-04-15 22:48 ` Andrii Nakryiko
2021-06-25 4:44 ` [PATCH bpf-next v3] " Rafael David Tinoco
2021-06-25 5:01 ` Rafael David Tinoco
2021-07-07 13:38 ` Rafael David Tinoco
2021-07-07 21:52 ` Andrii Nakryiko
2021-07-19 1:59 ` Rafael David Tinoco
2021-07-20 0:10 ` Andrii Nakryiko
2021-07-20 4:16 ` Rafael David Tinoco
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=318f936b-2f7c-7d4a-cb40-baf673bd6c9e@iogearbox.net \
--to=daniel@iogearbox.net \
--cc=andrii.nakryiko@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=rafaeldtinoco@ubuntu.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 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).