Re: [PATCH bpf-next 02/11] bpf: Refuse caller-supplied keyrings when the bpf one is active

> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 2beb61092bb31..543f245cc2557 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -673,6 +673,13 @@ Kernel parameters
>  			keys. Once the keyring is restricted it becomes active
>  			and can be used for BPF program signature verification.
>
> +			Setting this also means that the bpf keyring is the
> +			only keyring a loader may select for the rest of the
> +			boot: caller-supplied user/session keyrings are
> +			refused with -EPERM, whether or not provisioning
> +			actually completed. Leaving it unset keeps the prior
> +			behaviour, where a caller-supplied keyring is allowed.
> +

Is this paragraph accurate? It states the bpf keyring is "the only
keyring a loader may select" but the implementation allows system
keyrings to remain selectable:

kernel/bpf/verifier.c:bpf_prog_verify_signature() {
    if (!system_keyring_id_check(attr->keyring_id)) {
            key = bpf_lookup_system_key(attr->keyring_id);
    } else {
            if (attr->keyring_id != VERIFY_USE_BPF_KEYRING) {
                    if (bpf_keyring_enforced()) {
                            verbose(env, "caller-supplied keyring refused, use bpf keyring\n");
                            return -EPERM;
                    }
                    key = bpf_lookup_user_key(attr->keyring_id, 0);
            } else {
                    key = bpf_lookup_keyring();
            }
    }
}

system_keyring_id_check() accepts keyring_id values 0 (builtin), 1
(secondary), and 2 (platform), so a loader can still pass any of those
three ids and succeed. Only the user/session branch is refused.

The paragraph's lead-in sentence describes a stronger guarantee ("the only
keyring") than the code provides, while the clause after the colon correctly
describes the narrower behaviour ("caller-supplied user/session keyrings are
refused"). This is the text an operator reads when deciding their boot-time
trust configuration.

The more accurate phrasing appears in Documentation/bpf/signing.rst added
later in the series, which states "the only non-system keyring a loader may
select" and "The system keyrings stay selectable."

Could kernel-parameters.txt use the same "non-system keyring" qualifier?

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 3be8d51d35ac4..a93a8dc427d8c 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -21018,21 +21018,28 @@ static int bpf_prog_verify_signature(struct bpf_verifier_env *env,
>  	if (!attr->signature_size ||
>  	    attr->signature_size > KMALLOC_MAX_CACHE_SIZE)
>  		return -EINVAL;
> -	if (attr->keyring_id == VERIFY_USE_BPF_KEYRING) {
> -		key = bpf_lookup_keyring();
> -		if (!key) {
> -			verbose(env, "the bpf keyring is empty or has not been restricted\n");
> -			return -ENOKEY;
> -		}
> -	} else if (system_keyring_id_check(attr->keyring_id) == 0) {
> +	if (!system_keyring_id_check(attr->keyring_id)) {
>  		key = bpf_lookup_system_key(attr->keyring_id);
>  	} else {
> -		key = bpf_lookup_user_key(attr->keyring_id, 0);
> +		if (attr->keyring_id != VERIFY_USE_BPF_KEYRING) {
> +			if (bpf_keyring_enforced()) {
> +				verbose(env, "caller-supplied keyring refused, use bpf keyring\n");
> +				return -EPERM;
> +			}
> +			key = bpf_lookup_user_key(attr->keyring_id, 0);
> +		} else {
> +			key = bpf_lookup_keyring();
> +		}
>  	}

[ ... ]


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