BPF gains dedicated signing keyring and ML-DSA support

Daniel Borkmann has posted an 11-part series for bpf-next that introduces a dedicated kernel keyring for verifying signed BPF programs and extends bpftool and selftests to ML-DSA, the FIPS 204 post-quantum signature scheme.

The keyring is modelled on the dm-verity keyring so operators can enroll a BPF-only signing key at boot through the same enrollment path systemd already uses. A well-known keyring identifier selects it for program signature checks, giving signed BPF loads a trust root that is scoped to BPF rather than mixed with broader system keys.

A new boot parameter, bpf.keyring_unsealed=1, makes that keyring the sole trust anchor for the boot. Once set, caller-supplied user or session keyrings are refused with permission denied from the first program load onward. Leaving the flag unset keeps prior behaviour, so a caller-supplied keyring still works as a staging step for software whose signing key is not yet enrolled. Deriving the rule from the boot flag rather than keyring runtime state keeps the decision immutable from userspace. Systems that never enable the BPF keyring see no change.

To keep signing algorithm-agnostic in practice, the series also raises the upper bound on a program's signature blob to 64 KiB. The old limit was sized for RSA and ECDSA and is too small once ML-DSA signatures pass through the kernel's existing PKCS#7 verification path. bpftool learns to produce ML-DSA program signatures (with OpenSSL version-specific handling for CMS attributes), and selftests cover sealed and provisioned keyring lifecycles plus an end-to-end ML-DSA signed load so continuous integration exercises more than one algorithm.

Kernel documentation for BPF signing is expanded with RSA and ML-DSA key generation, load examples that name the BPF keyring as the primary trust root, and LSM admission sketches that treat caller-supplied keyrings as an explicit staging allowlist rather than ordinary trust.