Message-ID: <CAHC9VhSLOjQr4Ph2CefyEZGiB-Vqd4a8Y9=uA2YPo79Xo=Qopg@mail.gmail.com>
Date: Fri, 30 May 2025 16:14:52 -0400
From: Paul Moore <paul@...l-moore.com>
To: KP Singh <kpsingh@...nel.org>
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 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.

> > 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):

 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

Powered by blists - more mailing lists