Re: [PATCH bpf-next 1/2] bpf: Add hash chain signature support for arbitrary maps

[Blaise Boscaccy <bboscaccy@linux.microsoft.com>]

Quentin Monnet <qmo@kernel.org> writes:

> 2025-09-26 13:30 UTC-0700 ~ Blaise Boscaccy <bboscaccy@linux.microsoft.com>
>> This patch introduces hash chain support for signature verification of
>> arbitrary bpf map objects which was described here:
>> https://lore.kernel.org/linux-security-module/20250721211958.1881379-1-kpsingh@kernel.org/
>> 
>> The UAPI is extended to allow for in-kernel checking of maps passed in
>> via the fd_array. A hash chain is constructed from the maps, in order
>> specified by the signature_maps field. The hash chain is terminated
>> with the hash of the program itself.
>> 
>> Signed-off-by: Blaise Boscaccy <bboscaccy@linux.microsoft.com>
>> ---
>>  include/uapi/linux/bpf.h                      |  6 ++
>>  kernel/bpf/syscall.c                          | 73 ++++++++++++++++++-
>>  .../bpf/bpftool/Documentation/bpftool-gen.rst |  7 +-
>>  tools/bpf/bpftool/gen.c                       | 27 ++++++-
>>  tools/bpf/bpftool/main.c                      |  9 ++-
>>  tools/bpf/bpftool/main.h                      |  1 +
>>  tools/bpf/bpftool/sign.c                      | 17 ++++-
>>  tools/include/uapi/linux/bpf.h                |  6 ++
>>  tools/lib/bpf/libbpf.h                        |  3 +-
>>  tools/lib/bpf/skel_internal.h                 |  6 +-
>>  10 files changed, 143 insertions(+), 12 deletions(-)
>> 
>
> [...]
>
>> diff --git a/tools/bpf/bpftool/Documentation/bpftool-gen.rst b/tools/bpf/bpftool/Documentation/bpftool-gen.rst
>> index d0a36f442db72..b632ab87adf20 100644
>> --- a/tools/bpf/bpftool/Documentation/bpftool-gen.rst
>> +++ b/tools/bpf/bpftool/Documentation/bpftool-gen.rst
>> @@ -16,7 +16,7 @@ SYNOPSIS
>>  
>>  **bpftool** [*OPTIONS*] **gen** *COMMAND*
>>  
>> -*OPTIONS* := { |COMMON_OPTIONS| | { **-L** | **--use-loader** } | [ { **-S** | **--sign** } {**-k** <private_key.pem>} **-i** <certificate.x509> ] }
>> +*OPTIONS* := { |COMMON_OPTIONS| | { **-L** | **--use-loader** } | [ { **-S** | **--sign** } { **-M** | **--sign-maps** } {**-k** <private_key.pem>} **-i** <certificate.x509> ] }
>>  
>>  *COMMAND* := { **object** | **skeleton** | **help** }
>>  
>> @@ -190,6 +190,11 @@ OPTIONS
>>      For skeletons, generate a signed skeleton. This option must be used with
>>      **-k** and **-i**. Using this flag implicitly enables **--use-loader**.
>>  
>> +-M --sign-maps
>> +    For skeletons, generate a signed skeleton that includes a hash chain for the
>> +    skeletons maps. This option must be used with **-k** and **-i**. Using this
>> +    flag implicitly enables **--use-loader** and **--sign**.
>> +
>
>
> Hi! Pardon my ignorance, I haven't followed all the details of the
> discussions around signing. Is there a use case for signing the programs
> only (using -S) without signing the maps (using -M)? Or should we
> consider collapsing maps signing under the existing -S option?
>

Hi Quentin! Yes, there are some use cases where having both map signing
and program signing doesn't make much sense. For the light-skeleton use
case, where the map contains your actual program, it makes a lot of
sense. For other more dynamic use cases, maps can contain dynamically
generated user data or simply be providing program input and
output. Signing of those maps wouldn't provide much benefit, or even be
practical or possible in some scenarios. 

> If you do keep the new option, would you mind updating the bash
> completion file, please? Simply adding the long form like this:
>

> ------
>
> diff --git i/tools/bpf/bpftool/bash-completion/bpftool w/tools/bpf/bpftool/bash-completion/bpftool
> index 53bcfeb1a76e..f8c217f09989 100644
> --- i/tools/bpf/bpftool/bash-completion/bpftool
> +++ w/tools/bpf/bpftool/bash-completion/bpftool
> @@ -262,7 +262,7 @@ _bpftool()
>      # Deal with options
>      if [[ ${words[cword]} == -* ]]; then
>          local c='--version --json --pretty --bpffs --mapcompat --debug \
> -            --use-loader --base-btf --sign -i -k'
> +            --use-loader --base-btf --sign --sign-maps -i -k'
>          COMPREPLY=( $( compgen -W "$c" -- "$cur" ) )
>          return 0
>      fi
>
> ------

Of course. Thanks for the diff. I'll get that incorporated. 

>
> Other than that, the changes for bpftool look OK from my side. I'd
> probably split the patch further into kernel/libbpf/bpftool changes, but
> that's your call.
>

Sure, I'll get the userspace and kernel changes split out.

-blaise

> Thanks,
> Quentin