On Sun, May 4, 2025 at 7:36 PM Paul Moore paul@paul-moore.com wrote:
On Fri, May 2, 2025 at 5:00 PM KP Singh kpsingh@kernel.org wrote:
This patch series introduces the Hornet LSM. The goal of Hornet is to provide a signature verification mechanism for eBPF programs.
[...]
References: [1] https://lore.kernel.org/bpf/20220209054315.73833-1-alexei.starovoitov@gmail.... [2] https://lore.kernel.org/bpf/CAADnVQ+wPK1KKZhCgb-Nnf0Xfjk8M1UpX5fnXC=cBzdEYbv...
Change list: - v2 -> v3 - Remove any and all usage of proprietary bpf APIs
BPF APIs are not proprietary, but you cannot implement BPF program signing for BPF users without aligning with the BPF maintainers and the community. Signed programs are a UAPI and a key part of how developers experience BPF and this is not how we would like signing to be experienced by BPF users.
Some more feedback (which should be pretty obvious) but explicitly:
- Hacks like if (current->pid == 1) return 0; also break your threat model about root being untrusted.
Speaking with Blaise off-list when that change was discussed, I believe the intent behind that Kconfig option was simply for development/transition purposes, and not for any long term usage. My understanding is that this is why it was a separate build time configuration and not something that could be toggled at runtime, e.g. sysctl or similar.
You also did not take the feedback into account:
new = map->ops->map_lookup_elem(map, &key);
This is not okay without having the BPF maintainers aligned, the same way as
[...]
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.
Calling map->ops->map_lookup_elem wax objected to by Alexei. This feedback was not incorporated.
So for this approach, it's a:
Nacked-by: KP Singh kpsingh@kernel.org
Noted.
Now if you really care about the use-case and want to work with the maintainers and implement signing for the community, here's how we think it should be done:
- The core signing logic and the tooling stays in BPF, something that the users are already using. No new tooling.
I think we need a more detailed explanation of this approach on-list. There has been a lot of vague guidance on BPF signature validation from the BPF community which I believe has partly led us into the situation we are in now. If you are going to require yet another approach, I think we all need to see a few paragraphs on-list outlining the basic design.
Definitely, happy to share design / code.
- KP
- The policy decision on the effect of signing can be built into various existing LSMs. I don't think we need a new LSM for it.
- A simple UAPI (emphasis on UAPI!) change to union bpf_attr in uapi/bpf.h in the BPF_PROG_LOAD command:
__aligned_u64 signature; __u32 signature_size;
-- paul-moore.com