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: root@debian64:~/core# ./core [ 207.017086] prog '': relo #0: kind <byte_off> (0), spec is [ 207.017092] prog '': relo #0: matching candidate #0 [ 207.017172] prog '': relo #0: patched insn #2 (LDX/ST/STX) off 208 -> 208 [ 207.017239] prog '': relo #1: kind <byte_off> (0), spec is [ 207.017240] prog '': relo #1: matching candidate #0 [ 207.017269] prog '': relo #1: patched insn #3 (LDX/ST/STX) off 208 -> 208 [ 207.018232] prog '': relo #0: kind <byte_off> (0), spec is [ 207.018238] prog '': relo #0: matching candidate #0 [ 207.018322] prog '': relo #0: patched insn #2 (LDX/ST/STX) off 104 -> 104 [ 207.018384] prog '': relo #1: kind <byte_off> (0), spec is [ 207.018385] prog '': relo #1: matching candidate #0 [ 207.018411] prog '': relo #1: patched insn #3 (LDX/ST/STX) off 208 -> 208 [ 207.021003] prog '': relo #0: kind <byte_off> (0), spec is [ 207.021006] prog '': relo #0: matching candidate #0 [ 207.021104] prog '': relo #0: patched insn #2 (LDX/ST/STX) off 104 -> 104 [ 207.021167] prog '': relo #1: kind <byte_off> (0), spec is [ 207.021168] prog '': relo #1: matching candidate #0 [ 207.021196] prog '': relo #1: patched insn #3 (LDX/ST/STX) off 208 -> 208 Regards, -- per aspera ad upstream
