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, 22 Sep 2020 11:48:54 +0200
From:   Toke Høiland-Jørgensen <>
To:     Andrii Nakryiko <>
Cc:     Alexei Starovoitov <>,
        Daniel Borkmann <>,
        Martin KaFai Lau <>,
        Song Liu <>, Yonghong Song <>,
        Andrii Nakryiko <>,
        John Fastabend <>,
        Jiri Olsa <>,
        Eelco Chaudron <>,
        KP Singh <>,
        Networking <>, bpf <>
Subject: Re: [PATCH bpf-next v7 00/10] bpf: Support multi-attach for
 freplace programs

Andrii Nakryiko <> writes:

> On Sat, Sep 19, 2020 at 4:50 AM Toke Høiland-Jørgensen <> wrote:
>> This series adds support attaching freplace BPF programs to multiple targets.
>> This is needed to support incremental attachment of multiple XDP programs using
>> the libxdp dispatcher model.
>> The first patch fixes an issue that came up in review: The verifier will
>> currently allow MODIFY_RETURN tracing functions to attach to other BPF programs,
>> even though it is pretty clear from the commit messages introducing the
>> functionality that this was not the intention. This patch is included in the
>> serise because the subsequent refactoring patches touch the same code.
>> The next three patches are refactoring patches: Patch 2 is a trivial change to
>> the logging in the verifier, split out to make the subsequent refactor easier to
>> read. Patch 3 refactors check_attach_btf_id() so that the checks on program and
>> target compatibility can be reused when attaching to a secondary location.
>> Patch 4 moves prog_aux->linked_prog and the trampoline to be embedded in
>> bpf_tracing_link on attach, and freed by the link release logic, and introduces
>> a mutex to protect the writing of the pointers in prog->aux.
>> Based on these refactorings, it becomes pretty straight-forward to support
>> multiple-attach for freplace programs (patch 5). This is simply a matter of
>> creating a second bpf_tracing_link if a target is supplied. However, for API
>> consistency with other types of link attach, this option is added to the
>> BPF_LINK_CREATE API instead of extending bpf_raw_tracepoint_open().
>> Patch 6 is a port of Jiri Olsa's patch to support fentry/fexit on freplace
>> programs. His approach of getting the target type from the target program
>> reference no longer works after we've gotten rid of linked_prog (because the
>> bpf_tracing_link reference disappears on attach). Instead, we used the saved
>> reference to the target prog type that is also used to verify compatibility on
>> secondary freplace attachment.
>> Patches 7 is the accompanying libbpf update, and patches 8-10 are selftests:
>> patch 8 tests for the multi-freplace functionality itself, patch 9 is Jiri's
>> previous selftest for the fentry-to-freplace fix, and patch 10 is a test for
>> the change introduced in patch 1, blocking MODIFY_RETURN functions from
>> attaching to other BPF programs.
>> With this series, libxdp and xdp-tools can successfully attach multiple programs
>> one at a time. To play with this, use the 'freplace-multi-attach' branch of
>> xdp-tools:
>> $ git clone --recurse-submodules --branch freplace-multi-attach
>> $ cd xdp-tools/xdp-loader
>> $ make
>> $ sudo ./xdp-loader load veth0 ../lib/testing/xdp_drop.o
>> $ sudo ./xdp-loader load veth0 ../lib/testing/xdp_pass.o
>> $ sudo ./xdp-loader status
>> The series is also available here:
>> Changelog:
>> v7:
>>   - Add back missing ptype == prog->type check in link_create()
>>   - Use tracing_bpf_link_attach() instead of separate freplace_bpf_link_attach()
>>   - Don't break attachment of bpf_iters in libbpf
> What was specifically the issue and the fix for bpf_iters?

It was in libbpf - after making the attr passed to the kernel a union, I
was still unconditionally writing to the target_btf_id field, clobbering
the iter pointer. Which is also why it still happened even with a kernel
that didn't have the patch applied: I forgot to recompile the selftest :)


Powered by blists - more mailing lists