[PATCH bpf-next v2 0/3] BPF signature hash chains

[KP Singh]

On Thu, Oct 2, 2025 at 10:01 PM Blaise Boscaccy
<bboscaccy at linux.microsoft.com> wrote:
>
> KP Singh <kpsingh at kernel.org> writes:
>
> > On Wed, Oct 1, 2025 at 11:37 PM Paul Moore <paul at paul-moore.com> wrote:
> >>
> >
> > [...]
> >
>
> [...]
>
> I am confident that Paul will address your remaining points. However, I
> would like to clarify a few factual inaccuracies outlined below.
>
> >
> > Blaise's implementation fails on any modern BPF programs since
> > programs use more than one map, BTF information and kernel functions.
> >
>
> If you read the patch series you'd see that it supports verification of
> any number of maps. If you've identified an issue with map verification,
> please share the details and I’ll address it.
>

I am sorry but this does not work, the UAPI here is

+ /* Pointer to a buffer containing the maps used in the signature
+ * hash chain of the BPF program.
+ */
+ __aligned_u64   signature_maps;
+ /* Size of the signature maps buffer. */
+ __u32 signature_maps_size;

This needs to be generically applicable and it's not, What happens if
the program is not a loader program / when the instruction buffer is
stable?

If you really want the property that all of the content is signed and
verified within the kernel, please explore approaches to make the
instruction buffer stable or feel free to deny any programs that do
relocations at load time for whatever "strict" security policy that
you want to implement.

Please stop pursuing this extension as it adds cruft to the UAPI
that's too specific, encodes the hash chain in the kernel and we won't
need in the future.

> [...]
>
> >> conventions around the placement of LSM hooks, this "halfway" approach
> >> makes it difficult for LSMs to log anything about the signature status
> >> of a BPF program being loaded, or use the signature status in any type
> >> of access decision.  This is important for a number of user groups
> >> that use LSM based security policies as a way to help reason about the
> >> security properties of a system, as KP's scheme would require the
> >> users to analyze the signature verification code in every BPF light
> >> skeleton they authorize as well as the LSM policy in order to reason
> >> about the security mechanisms involved in BPF program loading.
> >>
> >> Blaise's signature scheme also has the nice property that BPF ELF
> >> objects created using his scheme are backwards compatible with
> >> existing released kernels that do not support any BPF signature
> >> verification schemes, of course without any signature verification.
> >> Loading a BPF ELF object using KP's signature scheme will likely fail
> >> when loaded on existing released kernels.
> >
> > This does not make any sense. The ELF format and the way loaders like
> > libbpf interpret it, has nothing to do with the kernel or UAPI.
> >
>
> We signed a program with your upstream tools and it failed to load on a
> vanilla kernel 6.16. The loader in your patchset is intepreting the
> first few fields of struct bpf_map as a byte array containing a sha256
> digest on older kernels.

We can convert BPF_OBJ_GET_INFO_BY_FD to be called from loader
programs to not rely on the struct field. and or libbbf can call
BPF_OBJ_GET_INFO_BY_FD to check if map_get_hash is supported before it
generates the hash check.

You should not expect bpftool -S -k -i to work on older kernels but it
should error out if the options are passed.

- KP

>
> -blaise
>
>
> > I had given detailed feedback to Blaise in
> > https://lore.kernel.org/bpf/CACYkzJ6yNjFOTzC04uOuCmFn=+51_ie2tB9_x-u2xbcO=yobTw@mail.gmail.com/
> > mentions also why we don't want any additional UAPI.
> >
> > You keep mentioning having visibility  in the LSM code and I again
> > ask, to implement what specific security policy and there is no clear
> > answer? On a system where you would like to only allow signed BPF
> > programs, you can purely deny any programs where the signature is not
> > provided and this can be implemented today.
> >
> > Stable programs work as it is, programs that require runtime
> > relocation work with loader programs. We don't want to add more UAPI
> > as, in the future, it's quite possible that we can make the
> > instruction buffer stable.
> >
> > - KP
> >
> >>
> >> [1] https://lore.kernel.org/linux-security-module/CAADnVQ+C2KNR1ryRtBGOZTNk961pF+30FnU9n3dt3QjaQu_N6Q@mail.gmail.com/
> >> [2] https://lore.kernel.org/linux-security-module/CAHC9VhRjKV4AbSgqb4J_-xhkWAp_VAcKDfLJ4GwhBNPOr+cvpg@mail.gmail.com/
> >> [3] https://lore.kernel.org/linux-security-module/87sei58vy3.fsf@microsoft.com/
> >> [4] https://lore.kernel.org/linux-security-module/20250909162345.569889-2-bboscaccy@linux.microsoft.com/
> >> [5] https://lore.kernel.org/linux-security-module/20250926203111.1305999-1-bboscaccy@linux.microsoft.com/
> >> [6] https://lore.kernel.org/linux-security-module/20250929213520.1821223-1-bboscaccy@linux.microsoft.com/
> >>
> >> --
> >> paul-moore.com