On Thu, Oct 08, 2026 at 09:44:46PM +0000, [email protected] wrote: > > keys: add KEY_SPEC_DM_VERITY_KEYRING > > TL;DR: Design/uapi question: was David Howells' v1 suggestion (reserved > negative key ID block, common register functions) intentionally dropped? The > new uapi value -10 should be settled before release. > > > diff --git a/include/uapi/linux/keyctl.h b/include/uapi/linux/keyctl.h > > --- a/include/uapi/linux/keyctl.h > > +++ b/include/uapi/linux/keyctl.h > > @@ -25,6 +25,7 @@ > > #define KEY_SPEC_REQKEY_AUTH_KEY -7 /* - key ID for assumed > > request_key auth key */ > > #define KEY_SPEC_REQUESTOR_KEYRING -8 /* - key ID for request_key() > > dest keyring */ > > #define KEY_SPEC_BPF_KEYRING -9 /* - key ID for the > > BPF-specific keyring */ > > +#define KEY_SPEC_DM_VERITY_KEYRING -10 /* - key ID for the .dm-verity > > keyring */ > > On v1, David Howells wrote: > > I have no particular objection to setting aside a block of negative key > IDs for special keyrings that need to be accessed a lot - though I would > make common reg/unreg functions that take the ID to be registered and, > say, set the block at -257..-512. Moving the BFP keyring to -257 and > DM to -258. > > (<[email protected]>) > > The question of whether this was being asked for v2 was raised in reply, but > there was no answer, and this version still continues the one-off -9/-10 > sequence with a dm-verity specific key_register_dm_verity_keyring() and > dm_verity_keyring_lock. > > Was the suggestion to use a reserved ID block with common register and > unregister functions intentionally dropped, or should it still be addressed? > > Since KEY_SPEC_DM_VERITY_KEYRING is a UAPI value, would it be possible to > settle this before the -10 value is released? >
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). > > --- > AI reviewed your patch. Please fix the bug or email reply why it's not a bug. > See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md > > CI run summary: https://github.com/kernel-patches/bpf/actions/runs/37844805282
