en Copyright 2015 Java http://kernelsources.org:8080/source/history/linux/kernel/bpf/keys.c#abaa0835b4f381067cc04bfd58180679d813578b bpf: Refuse caller-supplied keyrings when the bpf one is activeNothing changes for systems that do not use the bpf keyring. Withoutbpf.keyring_unsealed=1 a caller-supplied keyring behaves exactly asbefore, which also lets it serve as the staging step for softwareinstalled onto a running system whose signing key is not enrolledanywhere yet.Passing bpf.keyring_unsealed=1 states that the bpf keyring is the trustanchor for this boot, so from the first program load onwards a caller-supplied keyring is refused with -EPERM. Deriving this from the bootflag rather than from the keyring's runtime state keeps the decisionimmutable from userspace.Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>Link: https://lore.kernel.org/r/20260828175227.1537793-3-daniel@iogearbox.netSigned-off-by: Alexei Starovoitov <ast@kernel.org> List of files: /linux/kernel/bpf/keys.c Fri, 28 Aug 2026 19:52:18 +0200 Daniel Borkmann <daniel@iogearbox.net> http://kernelsources.org:8080/source/history/linux/kernel/bpf/keys.c#264d8fd2794fabe76a89abd5d4f5f8c1ed5fad85 bpf, keys: Add a bpf keyring for program signature validationBPF program signatures can currently be verified against one of thesystem keyrings (builtin, secondary, platform) or against an arbitraryuser/session caller-supplied keyring named through keyring_id. Thereis nothing in between: the system keyrings need a kernel rebuild or avouched-for enrollment to rotate a key, while a caller-supplied keyringis fully controlled by the loader and therefore carries no trust onits own (unless explicitly combined with BPF LSM to protect againstkey tampering).Add a dedicated bpf keyring to fill that gap, modelled after thedm-verity keyring which was added in commit 033724b1c627 ("dm-verity:add dm-verity keyring") and which can eventually be used also viasystemd [0] through the same enrollment method as in dm-verity's case.It is selected with the new KEY_SPEC_BPF_KEYRING special key id andgives an operator a place to enroll a BPF-only signing key at boot,specifically scoped to BPF program loading and nothing else in thekernel's trust hierarchy.The id is reserved from the KEY_SPEC space so that the latter is notlinked into any process keyring, and lookup_user_key() resolvesKEY_SPEC_BPF_KEYRING constant instead of having to look it up via/proc/keys first.By default the keyring is sealed empty at init. Systems that want toprovision keys pass bpf.keyring_unsealed=1, which leaves the keyringopen for the initrd to add keys to. The keyring is only ever consultedonce it is both non-empty and restricted. An unrestricted keyring isignored.Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>Link: https://github.com/systemd/systemd/pull/43549 [0]Link: https://lore.kernel.org/r/20260828175227.1537793-2-daniel@iogearbox.netSigned-off-by: Alexei Starovoitov <ast@kernel.org> List of files: /linux/kernel/bpf/keys.c Fri, 28 Aug 2026 19:52:17 +0200 Daniel Borkmann <daniel@iogearbox.net>