lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 8 Dec 2020 22:02:01 +0000 (GMT)
From:   Alan Maguire <>
To:     Andrii Nakryiko <>
cc:     Alan Maguire <>,
        Andrii Nakryiko <>, bpf <>,
        Networking <>,
        Alexei Starovoitov <>,
        Daniel Borkmann <>,
        Kernel Team <>
Subject: Re: [PATCH bpf-next] libbpf: support module BTF for BPF_TYPE_ID_TARGET
 CO-RE relocation

On Mon, 7 Dec 2020, Andrii Nakryiko wrote:

> On Sat, Dec 5, 2020 at 4:38 PM Alan Maguire <> wrote:
> > Thanks so much for doing this Andrii! When I tested, I ran into a problem;
> > it turns out when a module struct such as "veth_stats" is used, it's
> > classified as BTF_KIND_FWD, and as a result when we iterate over
> > the modules and look in the veth module, "struct veth_stats" does not
> > match since its module kind (BTF_KIND_STRUCT) does not match the candidate
> > kind (BTF_KIND_FWD). I'm kind of out of my depth here, but the below
> > patch (on top of your patch) worked.
> I'm not quite clear on the situation. BTF_KIND_FWD is for the local
> type or the remote type? Maybe a small example would help, before we
> go straight to assuming FWD can be always resolved into a concrete

The local type was BTF_KIND_FWD, and the target type was BTF_KIND_STRUCT
IIRC; I'll try and get some libbpf debug output for you showing the
relocation info.  If it helps, I think the situation was this; I was
referencing __builtin_btf_type_id(struct veth_stats), and hadn't
included a BTF-generated veth header, so I'm guessing libbpf classified
it as a fwd declaration.  My patch was a bit too general I suspect in
that it assumed that either target or local could be BTF_KIND_FWD and
should match BTF_KIND_STRUCT in local/target, wheres I _think_ the
local only should permit BTF_KIND_FWD.  Does that make sense? 
> >  However without it - when we find
> > 0  candidate matches - as well as not substituting the module object
> > id/type id - we hit a segfault:
> Yep, I missed the null check in:
> targ_spec->btf != prog->obj->btf_vmlinux
> I'll fix that.

Thanks! I think the core_reloc selftests trigger the segfault 
also if you need a test case to verify.


Powered by blists - more mailing lists