> So for this approach, it's a: > > Nacked-by: KP Singh <kpsingh@xxxxxxxxxx> 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. > * 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
