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

[KP Singh]

On Fri, Oct 3, 2025 at 8:14 PM Blaise Boscaccy
<bboscaccy at linux.microsoft.com> wrote:
>
> KP Singh <kpsingh at kernel.org> writes:
>
> > On Thu, Oct 2, 2025 at 10:01 PM Blaise Boscaccy
> > <bboscaccy at linux.microsoft.com> wrote:
> >>
> >> KP Singh <kpsingh at kernel.org> writes:

[...]

> >
> > 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?
> >
>
> The map array is fully configurable by the signer. Signing any or all
> maps is optional. If the instruction buffer is stable, the signer can
> generate the signature without maps and the caller passes zero in
> those fields.
>
> > If you really want the property that all of the content is signed and
> > verified within the kernel,
>
> That's what code signing is.

Sorry, this is wrong, allowing signed and trusted code to verify
subsequent executions is established in security.

Also you folks keep saying you want in-kernel verification, the loader
runs in the kernel, the same as any kernel code, so that requirement
is met. What you want is the logic to be hard coded in the kernel and
this goes against the BPF approach of flexibility.

>
> > 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.
> >
>
> If your primary complaint at this point is UAPI bloat, we'd be happy to
> rework the configurable hash-chain patch to use the existing signature
> buffer provided in your patchset.
>
> >> [...]
> >>
> >> >> conventions around the placement of LSM hooks, this "halfway" approach
> >> >> makes it difficult for LSMs to log anything about the signature status

[...]

> >>
> >> 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.
> >
>
> `bpftool gen` shouldn't have a priori knowledge of the target kernel
> version.

It can check whether the functionality is supported, it already does
it in many other places. I will follow-up with a fix for this.

- KP

>
> -blaise
>
>
> > - 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
> >> >
> >> >>

[...]

> >> >> --
> >> >> paul-moore.com