On Mon, May 5, 2025 at 4:41 PM KP Singh <kpsi...@kernel.org> wrote: > On Mon, May 5, 2025 at 7:30 PM Blaise Boscaccy > <bbosca...@linux.microsoft.com> wrote: > > > > KP Singh <kpsi...@kernel.org> writes: > > > > [...] > > > > > 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. > > > * 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; > > > > I think having some actual details on the various parties' requirements > > here would be helpful. KP, I do look forward to seeing your design; > > however, having code signing proposals where the capabilities are > > dictated from above and any dissent is dismissed as "you're doing it > > wrong" isn't going to be helpful to anyone that needs to use this in > > practice. > > Please don't misrepresent the facts ...
KP, I believe the most constructive thing at this point is to share your design idea with this thread as previously requested so everyone can review it. We can continue to argue about how we got to where we are at if you like, but that isn't likely to help us move towards a solution. If you are unable to share your design idea, either in a couple of paragraphs or in some form of PoC, please let us know. -- paul-moore.com
