On Thu, Oct 08, 2026 at 02:57:00PM -0700, Andrew Halaney wrote: > With the BPF keyring ID already being merged here in bpf-next, plus > Jarkko's feedback/RB, I continued following the current pattern instead > of walking back the BPF keyring ID, and dealing with the > builtin/module/rodata differences I alluded to that would make that > approach a little more annoying (at least with how I thought it thru).
Another data point for this design choice: after initial discussions with Fan Wu, I am about to propose a dedicated .ipe keyring for IPE policy-signature verification. The keyring would be exposed to userspace so that a trusted entity can provision keys, modeled after the .dm-verity keyring. I do not want to introduce churn to this discussion. I am happy to establish the reserved ID range and generic registration interface upon proposing my changeset, to establish this separately, or to follow any other suggestions. Getting guidance for this subject ahead of time for the case where 'yet another keyring' is introduced would be highly appreciated.
