From: Eric Biggers <ebiggers@kernel.org>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: KP Singh <kpsingh@kernel.org>, bpf <bpf@vger.kernel.org>,
LSM List <linux-security-module@vger.kernel.org>,
Blaise Boscaccy <bboscaccy@linux.microsoft.com>,
Paul Moore <paul@paul-moore.com>,
"K. Y. Srinivasan" <kys@microsoft.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>
Subject: Re: [PATCH v5 03/12] libbpf: Implement SHA256 internal helper
Date: Sat, 27 Sep 2025 16:04:12 -0700 [thread overview]
Message-ID: <20250927230412.GF9798@quark> (raw)
In-Reply-To: <CAADnVQ+t6JJ9YgH_xgicbzvvP2WvEJWxi+hioQtFKrR6BLTsCg@mail.gmail.com>
On Sat, Sep 27, 2025 at 11:33:12PM +0100, Alexei Starovoitov wrote:
> On Sat, Sep 27, 2025 at 10:03 PM Eric Biggers <ebiggers@kernel.org> wrote:
> >
> > On Sun, Sep 21, 2025 at 03:31:24PM +0200, KP Singh wrote:
> > > Use AF_ALG sockets to not have libbpf depend on OpenSSL. The helper is
> > > used for the loader generation code to embed the metadata hash in the
> > > loader program and also by the bpf_map__make_exclusive API to calculate
> > > the hash of the program the map is exclusive to.
> > >
> > > Acked-by: Andrii Nakryiko <andrii@kernel.org>
> > > Signed-off-by: KP Singh <kpsingh@kernel.org>
> >
> > Nacked-by: Eric Biggers <ebiggers@kernel.org>
> >
> > No more users of AF_ALG, please. It's a huge mistake and has been
> > incredibly problematic over the years.
>
> Lol. True, but good luck with that. AF_ALG is uapi and it will be removed
> only when the last user retires many years from now.
Many Linux systems never enabled AF_ALG in the first place, and those
that have it enabled often only have a few users of it or even none at
all. Sure, AF_ALG support will remain in-tree for a very long time or
even forever. But many systems can keep it disabled, or can disable it,
if new users are not introduced and existing users continue to be fixed.
Let's do the right thing here, instead of making the situation even
worse and also adding undocumented kconfig dependencies to libbpf.
> > If you don't want to depend on a library, then just include some basic
> > SHA-256 code, similar to what I'm doing for iproute2 and SHA-1 at
> > https://lore.kernel.org/netdev/20250925225322.13013-1-ebiggers@kernel.org/.
> > I'd even be glad to write the patch for you, if you want.
>
> Yes. Please. If you can craft sha256 without external dependencies
> we can certainly use it.
> Certainly agree that it would be better than AF_ALG.
Sure, I'll do that.
- Eric
next prev parent reply other threads:[~2025-09-27 23:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-21 13:31 [PATCH v5 00/12] Signed BPF programs KP Singh
2025-09-21 13:31 ` [PATCH v5 01/12] bpf: Update the bpf_prog_calc_tag to use SHA256 KP Singh
2025-09-21 13:31 ` [PATCH v5 02/12] bpf: Implement exclusive map creation KP Singh
2025-09-21 13:31 ` [PATCH v5 03/12] libbpf: Implement SHA256 internal helper KP Singh
2025-09-27 21:03 ` Eric Biggers
2025-09-27 22:33 ` Alexei Starovoitov
2025-09-27 23:04 ` Eric Biggers [this message]
2025-09-21 13:31 ` [PATCH v5 04/12] libbpf: Support exclusive map creation KP Singh
2025-09-21 13:31 ` [PATCH v5 05/12] selftests/bpf: Add tests for exclusive maps KP Singh
2025-09-21 13:31 ` [PATCH v5 06/12] bpf: Return hashes of maps in BPF_OBJ_GET_INFO_BY_FD KP Singh
2025-09-21 13:31 ` [PATCH v5 07/12] bpf: Move the signature kfuncs to helpers.c KP Singh
2025-09-21 13:31 ` [PATCH v5 08/12] bpf: Implement signature verification for BPF programs KP Singh
2025-09-21 13:31 ` [PATCH v5 09/12] libbpf: Update light skeleton for signing KP Singh
2025-09-21 13:31 ` [PATCH v5 10/12] libbpf: Embed and verify the metadata hash in the loader KP Singh
2025-09-21 13:31 ` [PATCH v5 11/12] bpftool: Add support for signing BPF programs KP Singh
2025-09-21 13:31 ` [PATCH v5 12/12] selftests/bpf: Enable signature verification for some lskel tests KP Singh
2025-09-21 15:31 ` [PATCH v5 00/12] Signed BPF programs Alexei Starovoitov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250927230412.GF9798@quark \
--to=ebiggers@kernel.org \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bboscaccy@linux.microsoft.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kpsingh@kernel.org \
--cc=kys@microsoft.com \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).