Message-ID: <875xhhn0jo.fsf@microsoft.com>
Date: Fri, 30 May 2025 16:25:47 -0700
From: Blaise Boscaccy <bboscaccy@...ux.microsoft.com>
To: KP Singh <kpsingh@...nel.org>
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

KP Singh <kpsingh@...nel.org> writes:

> On Sat, May 31, 2025 at 12:27 AM Blaise Boscaccy
> <bboscaccy@...ux.microsoft.com> wrote:
>>
>> KP Singh <kpsingh@...nel.org> writes:
>>
>> > On Sat, May 31, 2025 at 12:14 AM Blaise Boscaccy
>> > <bboscaccy@...ux.microsoft.com> wrote:
>> >>
>> >> KP Singh <kpsingh@...nel.org> writes:
>> >>
>> >> > On Fri, May 30, 2025 at 11:19 PM Blaise Boscaccy
>> >> > <bboscaccy@...ux.microsoft.com> wrote:
>> >> >>
>> >> >> KP Singh <kpsingh@...nel.org> writes:
>> >> >>
>> >> >
>> >> > [...]
>> >> >
>> >> >> >
>> >> >>
>> >> >> And that isn't at odds with the kernel being able to do it nor is it
>> >> >> with what I posted.
>> >> >>
>> >> >> > 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?
>> >> >> >
>> >> >>
>> >> >> Most people here can read C code. The number of people that can read
>> >> >> ebpf assembly metaprogramming code is much smaller. Compromising clang
>> >> >> is one thing, compromising libbpf is another. Your proposal increases
>> >> >> the attack surface with no observable benefit. If I was going to leave a
>> >> >> hard-to-find backdoor into ring0, gen.c would be a fun place to explore
>> >> >> doing it. Module and UEFI signature verification code doesn't live
>> >> >> inside of GCC or Clang as set of meta-instructions that get emitted, and
>> >> >> there are very good reasons for that.
>> >> >>
>> >> >> Further, since the signature verification code is unique for each and
>> >> >> every program it needs to be verified/proved/tested for each and every
>> >> >> program. Additionally, since all these checks are being forced outside
>> >> >> of the kernel proper, with the insistence of keeping the LSM layer in
>> >> >> the dark of the ultimate result, the only way to test that a program
>> >> >> will fail if the map is corrupted is to physically corrupt each and
>> >> >> every program and test that individually. That isn't "elegant" nor "user
>> >> >> friendly" in any way, shape or form.
>> >> >>
>> >> >> >> 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.
>> >> >> >
>> >> >>
>> >> >> I would like to be able to sign my programs please and have the kernel
>> >> >> verify it was done correctly. Why are you insisting that I *don't* do
>> >> >> that?  I'm yet to see any technical objection to doing that. Do you have
>> >> >> one that you'd like to share at this point?
>> >> >
>> >> > The kernel allows a trusted loader that's signed with your private
>> >> > key, that runs in the kernel context to delegate the verification.
>> >> > This pattern of a trusted / delegated loader is going to be required
>> >> > for many of the BPF use-cases that are out there (Cilium, bpftrace)
>> >> > that dynamically generate eBPF programs.
>> >> >
>> >> > The technical objection is that:
>> >> >
>> >> > * It does not align with most BPF use-cases out there as most
>> >> > use-cases need a trusted loader.
>> >>
>> >> No, it's definitely a use case. It's trivial to support both a trusted
>> >> loader and a signature over the hash chain of supplied assets.
>> >>
>> >> > * Locks us into a UAPI, whereas a signed LOADER allows us to
>> >> > incrementally build signing for all use-cases without compromising the
>> >> > security properties.
>> >> >
>> >>
>> >> Your proposal locks us into a UAPI as well. There is no way to make to
>> >> do this via UAPI without making a UAPI design choice.
>> >>
>> >> > BPF's philosophy is that of flexibility and not locking the users into
>> >> > a rigid in-kernel implementation and UAPI.
>> >> >
>> >>
>> >> Then why are you locking us into a rigid
>> >> only-signing-the-loader-is-allowed implementation?
>> >
>> > I explained this before, the delegated / trusted loader is needed by
>> > many BPF use-cases. A UAPI is forever, thus the lock-in.
>> >
>>
>> Again, I'm not following. What is technically wrong with supporting both
>> signing a loader only and allowing for the signature of multiple
>> passed-in assets? It's trivial to support both and any path forward will
>> force a UAPI lock-in.
>>
>> Do you simply feel that it isn't a valid use case and therefore we
>> shouldn't be allowed to do it?
>>
>
> I am saying both are not needed when one (trusted loader) handles all
> cases. You are writing / generating the loader anyways, you have the
> private key, the only thing to be done is add a few lines to the
> loader to verify an embedded hash.
>

And I'm saying that they are, based on wanting visibility in the LSM
layer, passing that along to the end user, and wanting to be able to
show correctness, along with mitigating an entire vector of supply chain
attacks targeting gen.c.

So in summary, your objection to this is that you feel it's simply "not
needed", and those above risks/design problems aren't actually an issue?

> Let's have this discussion in the patch series, much easier to discuss
> with the code.

I think we've all been waiting for that. Yes, lets.

Powered by blists - more mailing lists