Re: [PATCH bpf-next 05/11] selftests/bpf: Add a test for the sealed bpf keyring

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] API conflict and UAPI omission: The BPF system keyring sentinel value (3) collides with the valid user key serial number space.
--

--- Patch [5]: [PATCH bpf-next 05/11] selftests/bpf: Add a test for the sealed bpf keyring ---
commit 3de34ebcd8baa817e75280e15e9985c407307d98
Author: Daniel Borkmann <[email protected]>

selftests/bpf: Add a test for the sealed bpf keyring

This commit adds a selftest to ensure that loading a program naming the BPF
keyring fails with -ENOKEY when the keyring has not been provisioned. It
verifies the ordering of error checks prior to real signature processing.

> diff --git a/tools/testing/selftests/bpf/prog_tests/signed_loader.c b/tools/testing/selftests/bpf/prog_tests/signed_loader.c
> index 0c5294738d6ce..94b57e7cdab39 100644
> --- a/tools/testing/selftests/bpf/prog_tests/signed_loader.c
> +++ b/tools/testing/selftests/bpf/prog_tests/signed_loader.c
> @@ -32,8 +32,11 @@ enum {
>  	BPF_SIG_KEYRING_SECONDARY,
>  	BPF_SIG_KEYRING_PLATFORM,
>  	BPF_SIG_KEYRING_USER,
> +	BPF_SIG_KEYRING_BPF,
>  };
>  
> +#define BPF_KEYRING_BPF		3
> +

[Severity: Medium]
Does this hardcoded magic number (3) for the BPF keyring collide with the
valid user key serial number space?

Since key_alloc_serial() in security/keys/key.c only excludes values less
than 3, a user's dynamically allocated key serial could theoretically be
assigned serial 3.

If a user creates a keyring and happens to get assigned serial 3, and then
passes keyring_id = 3 to bpf_prog_load, wouldn't the verifier intercept it
via VERIFY_USE_BPF_KEYRING (which is defined as 3 in
include/linux/verification.h) and incorrectly route it to the .bpf system
keyring instead of the user's provided keyring?

Additionally, should this value be exposed via a UAPI header rather than
requiring user-space to hardcode it in the selftest?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=5