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

[Blaise Boscaccy]

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:
>>
>> > 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?
>

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. 

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

`bpftool gen` shouldn't have a priori knowledge of the target kernel
version. 

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