Re: [PATCH bpf-next v2 1/3] keys: add KEY_SPEC_DM_VERITY_KEYRING

[bot+bpf-ci]

> 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.

  (<715249.1789718726@xxxxxxxxxxxxxxxxxxxxxx>)

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?


---
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