[PATCH v3 0/4] Introducing Hornet LSM

[Daniel Borkmann]

On 5/4/25 7:36 PM, Paul Moore wrote:
> On Fri, May 2, 2025 at 5:00 PM KP Singh <kpsingh at 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 <kpsingh at kernel.org>
> 
> Noted.

Nacked-by: Daniel Borkmann <daniel at iogearbox.net>