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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 25 Jan 2022 03:39:04 +0000
From:   Dave Thaler <dthaler@...rosoft.com>
To:     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

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.

Dave