On Sun, Oct 11, 2026 at 09:35:43AM +0000, Manuel Huber wrote: > 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.
I think another keyring for just .ipe is fine if they want that. I wonder what you use ipe for. I've implemented ipe via a simple bpf lsm in userspace (well, for dm-verity. We don't use IMA or fsverity.). It's available in systemd itself.
