BPF series adds dedicated signing keyring and ML-DSA support

Daniel Borkmann has posted a second-round patch series for bpf-next that introduces a dedicated BPF keyring for signed program loading and extends bpftool so programs can be signed with ML-DSA, the NIST post-quantum signature scheme.

The new keyring is meant as a narrow trust root for BPF only. It follows the pattern used by dm-verity: an operator can enroll a BPF-specific signing key early in boot, after which the keyring can be restricted so it accepts no further keys. Loads that name this keyring then validate against that material alone. When the BPF keyring path is active, the kernel also refuses caller-supplied keyrings, so signature checks cannot silently fall back to a session or user keyring an untrusted process controls. A boot parameter can leave the keyring unsealed for provisioning and testing; a sealed boot is the intended production posture.

Separately, bpftool gains ML-DSA signing support on OpenSSL 3.x, with the CMS digest pinned to SHA-512 where signed attributes are required. ML-DSA-87 signatures are several kilobytes on their own, so bpftool's local signature buffer is raised to 16 KiB. The kernel side also lifts the bound on a program's signature size so larger post-quantum blobs can be presented at load time. The point is not only ML-DSA itself: the work is framed as proof that BPF program signing is algorithm-agnostic and can move with the rest of the kernel's crypto story.

Selftests cover a sealed keyring that rejects loads before provisioning, a full enroll-restrict-load cycle under an unsealed boot, and an end-to-end ML-DSA signed loader path. Documentation for BPF signing is expanded around the new keyring, staging versus committed trust, and key generation for both RSA and ML-DSA.

An automated review on the list flagged two follow-ups still open in this revision: whether clearing CMS_NOATTR for ML-DSA without suppressing signing-time attributes would make signatures non-reproducible, and whether the well-known BPF keyring selector collides with ordinary user keyring IDs.