On 5/4/25 7:36 PM, Paul Moore wrote:
On Fri, May 2, 2025 at 5:00 PM KP Singh <kpsi...@kernel.org> wrote:
[...]
 From what I've seen in Blaise's efforts to implement BPF signature
validation in the upstream kernel he has been working in good faith
and has been trying to work with the greater BPF community at each
step along the way.  He attempted to learn from previously rejected
attempts with his first patchset, however, that too was rejected, but
with feedback on how he might proceed.  Blaise took that feedback and
implemented Hornet, traveling to LSFMMBPF to present his idea to the
BPF community, as well as the usual mailing list postings.  When there
was feedback that certain APIs would not be permitted, despite being
EXPORT_SYMBOL'd, Blaise made some adjustments and came back to the
lists with an updated version.  You are obviously free to object to
portions of Hornet, but I don't believe you can claim Blaise isn't
trying to work with the BPF community on this effort.

We also discussed at LSFMMBPF that the current approach taken addresses
only a tiny fraction of BPF programs out there, meaning it will not be
applicable to 99% of projects utilizing BPF (e.g. for a OSS listing see
https://ebpf.io/applications/). What guidance would you provide to these
projects once this is set in place? "Please do a full rewrite (iff even
feasible) or accept user space breakage if some distro sets this generally
in place (wrongly assuming this provides a generic solution for all BPF)?"

In the presentation it was mentioned that you need something like Hornet
for your Azure Smart NICs in order to utilize BPF for livesite investigation
which is fine ofc, but given this only addresses a *tiny niche* of use cases,
the guidance given at the LSFMMBPF conference was to go via BPF LSM route
and implement it this way instead which Blaise agreed to look into. Given
this is a niche use case it is exactly the fit for BPF LSM.

So for this approach, it's a:

Nacked-by: KP Singh <kpsi...@kernel.org>

Noted.

Nacked-by: Daniel Borkmann <dan...@iogearbox.net>

Reply via email to