Re: [PATCH bpf-next v2 1/3] keys: add KEY_SPEC_DM_VERITY_KEYRING
From: Christian Brauner
Date: Mon Oct 12 2026 - 09:28:12 EST
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.