On Sun, May 4, 2025 at 7:36 PM Paul Moore <p...@paul-moore.com> wrote: > > On Fri, May 2, 2025 at 5:00 PM KP Singh <kpsi...@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.starovoi...@gmail.com/ > > > [2] > > > https://lore.kernel.org/bpf/CAADnVQ+wPK1KKZhCgb-Nnf0Xfjk8M1UpX5fnXC=cbzdeybv...@mail.gmail.com/ > > > > > > 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 <kpsi...@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
