On Thu, Dec 2, 2021 at 10:45 AM Matteo Croce <mcroce@xxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, Dec 1, 2021 at 7:11 PM Alexei Starovoitov > <alexei.starovoitov@xxxxxxxxx> wrote: > > > > From: Alexei Starovoitov <ast@xxxxxxxxxx> > > > > v4->v5: > > . Reduce number of memory allocations in candidate cache logic > > . Fix couple UAF issues > > . Add Andrii's patch to cleanup struct bpf_core_cand > > . More thorough tests > > . Planned followups: > > - support -v in lskel > > - move struct bpf_core_spec out of bpf_core_apply_relo_insn to > > reduce stack usage > > - implement bpf_core_types_are_compat > > > > v3->v4: > > . complete refactor of find candidates logic. > > Now it has small permanent cache. > > . Fix a bug in gen_loader related to attach_kind. > > . Fix BTF log size limit. > > . More tests. > > > > v2->v3: > > . addressed Andrii's feedback in every patch. > > New field in union bpf_attr changed from "core_relo" to "core_relos". > > . added one more test and checkpatch.pl-ed the set. > > > > v1->v2: > > . Refactor uapi to pass 'struct bpf_core_relo' from LLVM into libbpf and further > > into the kernel instead of bpf_core_apply_relo() bpf helper. Because of this > > change the CO-RE algorithm has an ability to log error and debug events through > > the standard bpf verifer log mechanism which was not possible with helper > > approach. > > . #define RELO_CORE macro was removed and replaced with btf_member_bit_offset() patch. > > > > This set introduces CO-RE support in the kernel. > > There are several reasons to add such support: > > 1. It's a step toward signed BPF programs. > > 2. It allows golang like languages that struggle to adopt libbpf > > to take advantage of CO-RE powers. > > 3. Currently the field accessed by 'ldx [R1 + 10]' insn is recognized > > by the verifier purely based on +10 offset. If R1 points to a union > > the verifier picks one of the fields at this offset. > > With CO-RE the kernel can disambiguate the field access. > > > > Hi, > > I ran my usual co-re test which was failing in the v1. Relocations > looks correct now: Matteo, Thanks for testing. May I ask you to take a stab at implementing non-recursive bpf_core_types_are_compat ? The libbpf version cannot be used as-is in the kernel. Or maybe we can limit its recursion to a few steps? In practice the limit of 2 is probably more than enough.