Re: [PATCH v2 2/3] keys: add KEY_SPEC_IPE_KEYRING

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] keys: KEY_SPEC_IPE_KEYRING uses -12 assuming nonexistent keyring IDs
--

commit 44da1efd13cdd5eb92238870e4d4626fe42f170e
Author: Manuel Huber <manuelh@nvidia.com>

keys: add KEY_SPEC_IPE_KEYRING

This commit adds the KEY_SPEC_IPE_KEYRING (-12) special key ID so that
userspace can directly reference the .ipe keyring via lookup_user_key()
without resolving it through process keyrings or /proc/keys.

>     keys: add KEY_SPEC_IPE_KEYRING
>     
>     The BPF, dm-verity, and fs-verity keyrings have well-known IDs which
>     allow userspace to directly address them. This commit follows the same
>     pattern for the .ipe keyring.
>     
>     This provides a direct interface independent of resolving %:.ipe through
>     process keyrings and /proc/keys.
>     
>     Signed-off-by: Manuel Huber <manuelh@nvidia.com>
> 
> diff --git a/Documentation/security/keys/core.rst b/Documentation/security/keys/core.rst
> index 326b8a9738289..64b37817a3356 100644
> --- a/Documentation/security/keys/core.rst
> +++ b/Documentation/security/keys/core.rst
> @@ -373,6 +373,18 @@ process making the call::
>  	KEY_SPEC_REQKEY_AUTH_KEY	-7	assumed request_key()
>  						  authorisation key
>  
> +There are also values that refer to a specific kernel keyring rather than to
> +anything belonging to the caller.  These well-known IDs allow userspace to
> +name kernel keyrings directly even when they are not linked into a process
> +keyring::
> +
> +	CONSTANT			VALUE	KEY REFERENCED
> +	==============================	======	===========================
> +	KEY_SPEC_IPE_KEYRING		-12	the ".ipe" keyring
> +
> +The availability of a subsystem keyring depends on its kernel configuration.
> +Looking up an unavailable keyring returns ``ENOKEY``.
> +
>  
>  The main syscalls are:
>  

[ ... ]

> diff --git a/include/uapi/linux/keyctl.h b/include/uapi/linux/keyctl.h
> index 4c8884eea8084..e42fca286b156 100644
> --- a/include/uapi/linux/keyctl.h
> +++ b/include/uapi/linux/keyctl.h
> @@ -24,6 +24,7 @@
>  #define KEY_SPEC_GROUP_KEYRING		-6	/* - key ID for GID-specific keyring */
>  #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_IPE_KEYRING		-12	/* - key ID for the .ipe keyring */

[Severity: Medium]
The commit message states that the BPF, dm-verity, and fs-verity keyrings
have well-known IDs, and defines KEY_SPEC_IPE_KEYRING as -12 immediately
after KEY_SPEC_REQUESTOR_KEYRING (-8) in include/uapi/linux/keyctl.h.

However, in the kernel tree, none of the BPF, dm-verity, or fs-verity
keyrings have KEY_SPEC_* IDs in include/uapi/linux/keyctl.h,
Documentation/security/keys/core.rst, or lookup_user_key() in
security/keys/process_keys.c.

This leaves an unexplained gap (-9 through -11) in the UAPI numbering and
makes KEY_SPEC_IPE_KEYRING (-12) the sole entry in the kernel keyring table
in Documentation/security/keys/core.rst.

Was this patch based on an unmerged series that assigned -9, -10, and -11 to
those keyrings, and should the numbering and commit description be adjusted
to match the current tree?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261029-b4-ipe-keyring-rfc-v2-0-77727b205844@nvidia.com?part=2