linux-kernel - Re: [PATCH 0/3] BPF signature verification

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACYkzJ4W9yhET8AnwvU5hhbP8nsH12sneqzKexVs6p4C596+sA@mail.gmail.com>
Date: Fri, 30 May 2025 22:44:32 +0200
From: KP Singh <kpsingh@...nel.org>
To: Paul Moore <paul@...l-moore.com>
Cc: Blaise Boscaccy <bboscaccy@...ux.microsoft.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 Fri, May 30, 2025 at 10:15 PM Paul Moore <paul@...l-moore.com> wrote:
>
> On Fri, May 30, 2025 at 12:42 PM KP Singh <kpsingh@...nel.org> wrote:
> > On Wed, May 28, 2025 at 11:50 PM Blaise Boscaccy
> > <bboscaccy@...ux.microsoft.com> wrote:
>
> ...
>
> > Please hold off on further iterations, I am working on a series and
> > will share these patches based on the design that was proposed.
>
> I don't think there is any harm in Blaise continuing his work in this
> area, especially as he seems to be making reasonable progress towards
> a solution that satisfies everyone's needs.  Considering all of the
> work that Blaise has already invested in this, and his continued
> willingness to try to work with everyone in the community to converge
> on a solution, wouldn't it be more beneficial to work with Blaise on
> further developing/refining his patchset instead of posting a parallel
> effort?  It's your call of course, I'm not going to tell you, or
> anyone else, to refrain from posting patches upstream, but it seems
> like this is a good opportunity to help foster the development of a
> new contributor.

I think Blaise's interactions leave a lot to be desired, especially as
a new contributor with the replies being unnecessarily abrasive, which
I am choosing to ignore.

Regardless, it would be more efficient to handle the subtleties here
if someone from the core BPF community implements this. This is why I
volunteered myself, but I need some time to wrap up the code and send
it on the list. Blaise can continue to send patches that don't
incorporate the feedback, it will only delay me further.

>
> > > 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.
>
> Excellent, I'm glad we can agree on the relative placement of the
> signature verification and the LSM hook.  Perhaps I misunderstood your
> design idea, but I took your comment:
>
> "The signature check in the verifier (during BPF_PROG_LOAD):

I meant during BPF_PROG_LOAD i.e. before the bpf_check is triggered,
as I said this is better explained when implemented.

>> trust me, friend” aspect of the original design.

The kernel is the TCB, both LSM and BPF are a part of the kernel and
part of the same trust domain, LSM has sufficient information in the
existing LSM hooks to enforce a signature policy and there is no need
for a boolean:

* If attr.signature is set, it's enforced, a new boolean does not
convey any new information here.
* If we specifically need auditing here, we can add an audit call in
the signature_verification method, this can be done in a follow-up
series.


>
>  verify_pkcs7_signature(prog->aux->sha, sizeof(prog->aux->sha),
>    sig_from_bpf_attr, …);"
>
> https://lore.kernel.org/linux-security-module/CACYkzJ6VQUExfyt0=-FmXz46GHJh3d=FXh5j4KfexcEFbHV-vg@mail.gmail.com/
>
> ... to mean that the PKCS7 signature verification was going to happen
> *in* the verifier, with the verifier being bpf_check().  Simply for my
> own education, if bpf_check() and/or the bpf_check() call in
> bpf_prog_load() is not the verifier, it would be helpful to know that,
> and also what code is considered the be the BPF verifier.  Regardless,
> it's a good step forward that we are all on the same page with respect
> to the authorization of signed/unsigned BPF programs.  We still have a
> ways to go it looks like, but we're making good progress.
>
> --
> paul-moore.com