netdev - Re: Bpftool mirror now available

lists.openwall.net		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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1e45d3ed-7fcf-81d2-ae68-5b93467a3d32@iogearbox.net>
Date:   Tue, 25 Jan 2022 22:42:07 +0100
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Dave Thaler <dthaler@...rosoft.com>,
        Quentin Monnet <quentin@...valent.com>,
        bpf <bpf@...r.kernel.org>, Networking <netdev@...r.kernel.org>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        Andrii Nakryiko <andrii@...nel.org>
Subject: Re: Bpftool mirror now available

On 1/25/22 4:39 AM, Dave Thaler wrote:
> Quentin Monnet <quentin@...valent.com> writes:
>> Another thing to consider is that keeping bpftool next to the kernel sources
>> has been useful to help keeping the tool in sync, for example for adding new
>> type names to bpftool's lists when the kernel get new program/map types.
>> We have recently introduced some CI checks that could be adjusted to work
>> with an external repo and mitigate this issue, but still, it is harder to tell people
>> to submit changes to a second repository when what they want is just to update
>> the kernel. I fear this would result in a bit more maintenance on bpftool's side
>> (but then bpftool's requirements in terms of maintenance are not that big
>> when compared to bigger tools, and maybe some of it could be automated).
>>
>> Then the other solution, as you mentioned, would be to take Windows-related
>> patches for bpftool in the Linux repo. For what it's worth, I don't have any
>> personal objection to it, but it raises the problems of testing and ownership
>> (who fixes bugs) for these patches.
> 
> Personally I would recommend a third approach.   That is, bpftool today
> combines both platform-agnostic code and platform-specific code without
> clean factoring between them.  Instead I would want to see it factored such
> that there is a clean API between them, where the platform-agnostic code
> can be out-of-tree, and the platform-specific code can be in-tree.   This would
> allow Windows platform-specific code to similarly be in-tree for the ebpf-for-windows project.  Both the Linux kernel and ebpf-for-windows (and any other
> future platforms) can then depend on the out-of-tree code along with their
> own platform-specific code needed to build and run on their own platform.
> That's roughly the approach that I've taken for some other projects where it
> has worked well.

I wouldn't mind if tools/bpf/bpftool/ would see some refactoring effort to
make it more platform-agnostic, similar as kernel split out arch/ bits vs
generic code. Needed bits should however still be somewhere under bpftool
dir in the tree, at least for Linux, so that patch series touching kernel +
libbpf + bpftool can be run by the existing CI w/o extra detour to first
patch or requiring feature branch on some external out-of-tree dependency.
Perhaps it would be possible to have platform-specific code pluggable via
lib as one of the build options for bpftool..

Thanks,
Daniel