On Fri, May 10, 2019 at 11:41:50AM -0700, Andrii Nakryiko wrote:
> Depending on used versions of libbpf, Clang, and kernel, it's possible to
> have valid BPF object files with valid BTF information, that still won't
> load successfully due to Clang emitting newer BTF features (e.g.,
> BTF_KIND_FUNC, .BTF.ext's line_info/func_info, BTF_KIND_DATASEC, etc), that
> are not yet supported by older kernel.
>
> This patch adds detection of BTF features and sanitizes BPF object's BTF
> by substituting various supported BTF kinds, which have compatible layout:
> - BTF_KIND_FUNC -> BTF_KIND_TYPEDEF
> - BTF_KIND_FUNC_PROTO -> BTF_KIND_ENUM
> - BTF_KIND_VAR -> BTF_KIND_INT
> - BTF_KIND_DATASEC -> BTF_KIND_STRUCT
>
> Replacement is done in such a way as to preserve as much information as
> possible (names, sizes, etc) where possible without violating kernel's
> validation rules.
>
> v1->v2:
> - add internal libbpf_util.h w/ common stuff
> - switch SK storage BTF to use new libbpf__probe_raw_btf()
>
> Reported-by: Alexei Starovoitov <a...@fb.com>
> Signed-off-by: Andrii Nakryiko <andr...@fb.com>
...
> diff --git a/tools/lib/bpf/libbpf_util.h b/tools/lib/bpf/libbpf_util.h
> index da94c4cb2e4d..319e744eb33a 100644
> --- a/tools/lib/bpf/libbpf_util.h
> +++ b/tools/lib/bpf/libbpf_util.h
> @@ -57,4 +57,16 @@ do { \
> } /* extern "C" */
> #endif
>
> +#define BTF_INFO_ENC(kind, kind_flag, vlen) \
> + ((!!(kind_flag) << 31) | ((kind) << 24) | ((vlen) & BTF_MAX_VLEN))
> +#define BTF_TYPE_ENC(name, info, size_or_type) (name), (info), (size_or_type)
> +#define BTF_INT_ENC(encoding, bits_offset, nr_bits) \
> + ((encoding) << 24 | (bits_offset) << 16 | (nr_bits))
> +#define BTF_TYPE_INT_ENC(name, encoding, bits_offset, bits, sz) \
> + BTF_TYPE_ENC(name, BTF_INFO_ENC(BTF_KIND_INT, 0, 0), sz), \
> + BTF_INT_ENC(encoding, bits_offset, bits)
> +#define BTF_MEMBER_ENC(name, type, bits_offset) (name), (type), (bits_offset)
> +#define BTF_PARAM_ENC(name, type) (name), (type)
> +#define BTF_VAR_SECINFO_ENC(type, offset, size) (type), (offset), (size)
hmm. why are those needed in libbpf_util.h ?
I thought the goal is move them into libbpf_internal.h
and not to expose to users?
