Message-ID: <CACYkzJ5oJASZ43B531gY8mESqAF3WYFKez-H5vKxnk8r48Ouxg@mail.gmail.com>
Date: Fri, 30 May 2025 18:42:05 +0200
From: KP Singh <kpsingh@...nel.org>
To: Blaise Boscaccy <bboscaccy@...ux.microsoft.com>
Cc: Paul Moore <paul@...l-moore.com>, jarkko@...nel.org, zeffron@...tgames.com, 
	xiyou.wangcong@...il.com, kysrinivasan@...il.com, code@...icks.com, 
	linux-security-module@...r.kernel.org, roberto.sassu@...wei.com, 
	James.Bottomley@...senpartnership.com, Alexei Starovoitov <ast@...nel.org>, 
	Daniel Borkmann <daniel@...earbox.net>, John Fastabend <john.fastabend@...il.com>, 
	Andrii Nakryiko <andrii@...nel.org>, Martin KaFai Lau <martin.lau@...ux.dev>, 
	Eduard Zingerman <eddyz87@...il.com>, Song Liu <song@...nel.org>, 
	Yonghong Song <yonghong.song@...ux.dev>, Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>, 
	Jiri Olsa <jolsa@...nel.org>, David Howells <dhowells@...hat.com>, Lukas Wunner <lukas@...ner.de>, 
	Ignat Korchagin <ignat@...udflare.com>, Quentin Monnet <qmo@...nel.org>, 
	Jason Xing <kerneljasonxing@...il.com>, Willem de Bruijn <willemb@...gle.com>, 
	Anton Protopopov <aspsk@...valent.com>, Jordan Rome <linux@...danrome.com>, 
	Martin Kelly <martin.kelly@...wdstrike.com>, Alan Maguire <alan.maguire@...cle.com>, 
	Matteo Croce <teknoraver@...a.com>, bpf@...r.kernel.org, linux-kernel@...r.kernel.org, 
	keyrings@...r.kernel.org, linux-crypto@...r.kernel.org, kys@...rosoft.com
Subject: Re: [PATCH 0/3] BPF signature verification

On Wed, May 28, 2025 at 11:50 PM Blaise Boscaccy
<bboscaccy@...ux.microsoft.com> wrote:
>
> As suggested or mandated by KP Singh
> https://lore.kernel.org/linux-security-module/CACYkzJ6VQUExfyt0=-FmXz46GHJh3d=FXh5j4KfexcEFbHV-vg@mail.gmail.com/,
> this patchset proposes and implements an alternative hash-chain
> algorithm for signature verification of BPF programs.
>
>
>
> This design diverges in two key ways:
>
> 1. Signature Strategy
>
> Two different signature strategies are
> implemented. One verifies only the signature of the loader program in
> the kernel, as described in the link above. The other verifies the
> program’s maps in-kernel via a hash chain.  The original design
> required loader programs to be “self-aborting” and embedded the
> terminal hash verification logic as metaprogramming code generation
> routines inside libbpf. While this patchset supports that scheme, it
> is considered undesirable in certain environments due to the potential
> for supply-chain attack vectors and the lack of visibility for the LSM

The loader program is signed by a trusted entity, If you trust the
signature, then you trust it to do the signature verification. This is
a fairly common pattern in security and a pattern that we will be
using in other signed bpf use-cases which can choose to depend on
signed loaders.

If your build environment that signs the BPF program is compromised
and can inject arbitrary code, then signing does not help.  Can you
explain what a supply chain attack would look like here?

> subsystem.  Additionally, it is impossible to verify the code
> performing the signature verification, as it is uniquely regenerated

The LSM needs to ensure that it allows trusted LOADER programs i.e.
with signatures and potentially trusted signed user-space binaries
with unsigned or delegated signing (this will be needed for Cilium and
bpftrace that dynamically generate BPF programs), that's a more
important aspect of the LSM policy from a BPF perspective.

MAP_EXCLUSIVE is missing and is required which prevents maps from
being accessed by other programs as explained in the proposal.

Please hold off on further iterations, I am working on a series and
will share these patches based on the design that was proposed.

>
> for every program.
>
>
>
> 2. Timing of Signature Check
>
> This patchset moves the signature check to a point before
> security_bpf_prog_load is invoked, due to an unresolved discussion
> here:

This is fine and what I had in mind, signature verification does not
need to happen in the verifier and the existing hooks are good enough.
I did not reply to Paul's comment since this is a fairly trivial
detail and would be obvious in the implementation that the verifier is
not the right place to check the signature anyways as the instruction
buffer is only stable pre-verification.

> https://lore.kernel.org/linux-security-module/CAHC9VhTj3=ZXgrYMNA+G64zsOyZO+78uDs1g=kh91=GR5KypYg@mail.gmail.com/
> This change allows the LSM subsystem to be informed of the signature
> verification result—if it occurred—and the method used, all without
> introducing a new hook. It improves visibility and auditability,
> reducing the “trust me, friend” aspect of the original design.


On Wed, May 28, 2025 at 11:50 PM Blaise Boscaccy
<bboscaccy@...ux.microsoft.com> wrote:
>
> As suggested or mandated by KP Singh
> https://lore.kernel.org/linux-security-module/CACYkzJ6VQUExfyt0=-FmXz46GHJh3d=FXh5j4KfexcEFbHV-vg@mail.gmail.com/,
> this patchset proposes and implements an alternative hash-chain
> algorithm for signature verification of BPF programs.
>
> This design diverges in two key ways:
>
> 1. Signature Strategy
>
> Two different signature strategies are
> implemented. One verifies only the signature of the loader program in
> the kernel, as described in the link above. The other verifies the
> program’s maps in-kernel via a hash chain.  The original design
> required loader programs to be “self-aborting” and embedded the
> terminal hash verification logic as metaprogramming code generation
> routines inside libbpf. While this patchset supports that scheme, it
> is considered undesirable in certain environments due to the potential
> for supply-chain attack vectors and the lack of visibility for the LSM
> subsystem.  Additionally, it is impossible to verify the code
> performing the signature verification, as it is uniquely regenerated
> for every program.
>
> 2. Timing of Signature Check
>
> This patchset moves the signature check to a point before
> security_bpf_prog_load is invoked, due to an unresolved discussion
> here:
> https://lore.kernel.org/linux-security-module/CAHC9VhTj3=ZXgrYMNA+G64zsOyZO+78uDs1g=kh91=GR5KypYg@mail.gmail.com/
> This change allows the LSM subsystem to be informed of the signature
> verification result—if it occurred—and the method used, all without
> introducing a new hook. It improves visibility and auditability,
> reducing the “trust me, friend” aspect of the original design.
>
>
> Blaise Boscaccy (3):
>   bpf: Add bpf_check_signature
>   bpf: Support light-skeleton signatures in autogenerated code
>   bpftool: Allow signing of light-skeleton programs
>
>  include/linux/bpf.h            |   2 +
>  include/linux/verification.h   |   1 +
>  include/uapi/linux/bpf.h       |   4 +
>  kernel/bpf/arraymap.c          |  11 +-
>  kernel/bpf/syscall.c           | 123 +++++++++++++++++++-
>  tools/bpf/bpftool/Makefile     |   4 +-
>  tools/bpf/bpftool/common.c     | 204 +++++++++++++++++++++++++++++++++
>  tools/bpf/bpftool/gen.c        |  66 ++++++++++-
>  tools/bpf/bpftool/main.c       |  24 +++-
>  tools/bpf/bpftool/main.h       |  23 ++++
>  tools/include/uapi/linux/bpf.h |   4 +
>  tools/lib/bpf/libbpf.h         |   4 +
>  tools/lib/bpf/skel_internal.h  |  28 ++++-
>  13 files changed, 491 insertions(+), 7 deletions(-)
>
> --
> 2.48.1
>

Powered by blists - more mailing lists