On Mon, 2025-05-05 at 22:41 +0200, KP Singh wrote: > On Mon, May 5, 2025 at 7:30 PM Blaise Boscaccy > <bboscaccy@xxxxxxxxxxxxxxxxxxx> wrote: > > > > KP Singh <kpsingh@xxxxxxxxxx> 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, you got feedback from Alexei in > various threads, but you chose to argue on the points that were > convenient for you (i.e. usage of BPF internal APIs) and yet you > claim to "work with the BPF community and maintainers" by arguing > instead of collaborating and paying attention to the feedback given > to you. I'm with Paul on this: if you could share your design ideas more fully than you have above that would help make this debate way more technical. However, I will try to respond to the other technical points from a general security point of view if it helps but I've made some guesses about what will work for you. [...] > 2. Alexei suggested to you in > https://lore.kernel.org/bpf/87plhhjwqy.fsf@xxxxxxxxxxxxx/ > > "A signature for the map plus a signature for the prog > that is tied to a map might be a better option. > At map creation time the contents can be checked, > the map is frozen, and then the verifier can proceed > with prog's signature checking." > > You never replied to this.
