Message-ID: <87bjr9n3st.fsf@microsoft.com>
Date: Fri, 30 May 2025 15:15:30 -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 Fri, May 30, 2025 at 11:32 PM KP Singh <kpsingh@...nel.org> wrote:
>>
>> 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.
>> * Locks us into a UAPI, whereas a signed LOADER allows us to
>> incrementally build signing for all use-cases without compromising the
>> security properties.
>>
>> BPF's philosophy is that of flexibility and not locking the users into
>> a rigid in-kernel implementation and UAPI.
>>
>> - KP
>>
>> >
>> > > 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.
>> > >
>> >
>> > So the premise here seems to be that people should only be allowed to
>> > sign trusted loaders, and that trusted loaders must additionally be
>> > authored by you, correct?
>> >
>> > When can we expect to see your patchset posted?
>
> I will try to get this out by the end of next week.

Wonderful, we look forward to seeing your patchset.

-blaise

>
> - KP
>
>> >

Powered by blists - more mailing lists