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

[Blaise Boscaccy]

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.


[...]

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

-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