On 3/18/21 8:46 PM, Andrii Nakryiko wrote:
On Thu, Mar 18, 2021 at 12:31 PM Rafael David Tinoco
<rafaeldtinoco@xxxxxxxxxx> 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@xxxxxxxxxx>
---
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
