[PATCH iproute2-next v2] lib/bpf_legacy: Use userspace SHA-1 code instead of AF_ALG

[PATCH iproute2-next v2] lib/bpf_legacy: Use userspace SHA-1 code instead of AF_ALG

[Eric Biggers]

Add a basic SHA-1 implementation to lib/, and make lib/bpf_legacy.c use
it to calculate SHA-1 digests instead of the previous AF_ALG-based code.

This eliminates the dependency on AF_ALG, specifically the kernel config
options CONFIG_CRYPTO_USER_API_HASH and CONFIG_CRYPTO_SHA1.

Over the years AF_ALG has been very problematic, and it is also not
supported on all kernels.  Escalating to the kernel's privileged
execution context merely to calculate software algorithms, which can be
done in userspace instead, is not something that should have ever been
supported.  Even on kernels that support it, the syscall overhead of
AF_ALG means that it is often slower than userspace code.

Let's do the right thing here, and allow people to disable AF_ALG
support (or not enable it) on systems where iproute2 is the only user.

Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
---

Changed in v2:
    - Corrected error handling for when bpf_obj_hash() fails
    - Added more detail to commit message

 include/bpf_util.h          |   5 --
 include/sha1.h              |  18 ++++++
 include/uapi/linux/if_alg.h |  61 --------------------
 lib/Makefile                |   2 +-
 lib/bpf_legacy.c            | 109 +++++++++---------------------------
 lib/sha1.c                  | 108 +++++++++++++++++++++++++++++++++++
 6 files changed, 154 insertions(+), 149 deletions(-)
 create mode 100644 include/sha1.h
 delete mode 100644 include/uapi/linux/if_alg.h
 create mode 100644 lib/sha1.c

diff --git a/include/bpf_util.h b/include/bpf_util.h
index 8951a5e8..e1b8d327 100644
--- a/include/bpf_util.h
+++ b/include/bpf_util.h
@@ -12,11 +12,10 @@
 #include <linux/bpf.h>
 #include <linux/btf.h>
 #include <linux/filter.h>
 #include <linux/magic.h>
 #include <linux/elf-em.h>
-#include <linux/if_alg.h>
 
 #include "utils.h"
 #include "bpf_scm.h"
 
 #define BPF_ENV_UDS	"TC_BPF_UDS"
@@ -38,14 +37,10 @@
 # define TRACEFS_MAGIC	0x74726163
 #endif
 
 #define TRACE_DIR_MNT	"/sys/kernel/tracing"
 
-#ifndef AF_ALG
-# define AF_ALG		38
-#endif
-
 #ifndef EM_BPF
 # define EM_BPF		247
 #endif
 
 struct bpf_cfg_ops {
diff --git a/include/sha1.h b/include/sha1.h
new file mode 100644
index 00000000..4a2ed513
--- /dev/null
+++ b/include/sha1.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * SHA-1 message digest algorithm
+ *
+ * Copyright 2025 Google LLC
+ */
+#ifndef __SHA1_H__
+#define __SHA1_H__
+
+#include <linux/types.h>
+#include <stddef.h>
+
+#define SHA1_DIGEST_SIZE 20
+#define SHA1_BLOCK_SIZE 64
+
+void sha1(const __u8 *data, size_t len, __u8 out[SHA1_DIGEST_SIZE]);
+
+#endif /* __SHA1_H__ */
diff --git a/include/uapi/linux/if_alg.h b/include/uapi/linux/if_alg.h
deleted file mode 100644
index 0824fbc0..00000000
--- a/include/uapi/linux/if_alg.h
+++ /dev/null
@@ -1,61 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */
-/*
- * if_alg: User-space algorithm interface
- *
- * Copyright (c) 2010 Herbert Xu <herbert@gondor.apana.org.au>
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the Free
- * Software Foundation; either version 2 of the License, or (at your option)
- * any later version.
- *
- */
-
-#ifndef _LINUX_IF_ALG_H
-#define _LINUX_IF_ALG_H
-
-#include <linux/types.h>
-
-struct sockaddr_alg {
-	__u16	salg_family;
-	__u8	salg_type[14];
-	__u32	salg_feat;
-	__u32	salg_mask;
-	__u8	salg_name[64];
-};
-
-/*
- * Linux v4.12 and later removed the 64-byte limit on salg_name[]; it's now an
- * arbitrary-length field.  We had to keep the original struct above for source
- * compatibility with existing userspace programs, though.  Use the new struct
- * below if support for very long algorithm names is needed.  To do this,
- * allocate 'sizeof(struct sockaddr_alg_new) + strlen(algname) + 1' bytes, and
- * copy algname (including the null terminator) into salg_name.
- */
-struct sockaddr_alg_new {
-	__u16	salg_family;
-	__u8	salg_type[14];
-	__u32	salg_feat;
-	__u32	salg_mask;
-	__u8	salg_name[];
-};
-
-struct af_alg_iv {
-	__u32	ivlen;
-	__u8	iv[];
-};
-
-/* Socket options */
-#define ALG_SET_KEY			1
-#define ALG_SET_IV			2
-#define ALG_SET_OP			3
-#define ALG_SET_AEAD_ASSOCLEN		4
-#define ALG_SET_AEAD_AUTHSIZE		5
-#define ALG_SET_DRBG_ENTROPY		6
-#define ALG_SET_KEY_BY_KEY_SERIAL	7
-
-/* Operations */
-#define ALG_OP_DECRYPT			0
-#define ALG_OP_ENCRYPT			1
-
-#endif	/* _LINUX_IF_ALG_H */
diff --git a/lib/Makefile b/lib/Makefile
index 0ba62942..ee1e2e87 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -4,11 +4,11 @@ include ../config.mk
 CFLAGS += -fPIC
 
 UTILOBJ = utils.o utils_math.o rt_names.o ll_map.o ll_types.o ll_proto.o ll_addr.o \
 	inet_proto.o namespace.o json_writer.o json_print.o json_print_math.o \
 	names.o color.o bpf_legacy.o bpf_glue.o exec.o fs.o cg_map.o \
-	ppp_proto.o bridge.o
+	ppp_proto.o bridge.o sha1.o
 
 ifeq ($(HAVE_ELF),y)
 ifeq ($(HAVE_LIBBPF),y)
 UTILOBJ += bpf_libbpf.o
 endif
diff --git a/lib/bpf_legacy.c b/lib/bpf_legacy.c
index c8da4a3e..50ca82c1 100644
--- a/lib/bpf_legacy.c
+++ b/lib/bpf_legacy.c
@@ -27,18 +27,19 @@
 
 #include <sys/types.h>
 #include <sys/stat.h>
 #include <sys/un.h>
 #include <sys/vfs.h>
+#include <sys/mman.h>
 #include <sys/mount.h>
-#include <sys/sendfile.h>
 #include <sys/resource.h>
 
 #include <arpa/inet.h>
 
 #include "utils.h"
 #include "json_print.h"
+#include "sha1.h"
 
 #include "bpf_util.h"
 #include "bpf_elf.h"
 #include "bpf_scm.h"
 
@@ -1178,11 +1179,10 @@ struct bpf_elf_ctx {
 	int			sec_btf;
 	char			license[ELF_MAX_LICENSE_LEN];
 	enum bpf_prog_type	type;
 	__u32			ifindex;
 	bool			verbose;
-	bool			noafalg;
 	struct bpf_elf_st	stat;
 	struct bpf_hash_entry	*ht[256];
 	char			*log;
 	size_t			log_size;
 };
@@ -1306,76 +1306,32 @@ static int bpf_obj_pin(int fd, const char *pathname)
 	attr.bpf_fd = fd;
 
 	return bpf(BPF_OBJ_PIN, &attr, sizeof(attr));
 }
 
-static int bpf_obj_hash(const char *object, uint8_t *out, size_t len)
+static int bpf_obj_hash(int fd, const char *object, __u8 out[SHA1_DIGEST_SIZE])
 {
-	struct sockaddr_alg alg = {
-		.salg_family	= AF_ALG,
-		.salg_type	= "hash",
-		.salg_name	= "sha1",
-	};
-	int ret, cfd, ofd, ffd;
 	struct stat stbuff;
-	ssize_t size;
-
-	if (!object || len != 20)
-		return -EINVAL;
-
-	cfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
-	if (cfd < 0)
-		return cfd;
+	void *data;
 
-	ret = bind(cfd, (struct sockaddr *)&alg, sizeof(alg));
-	if (ret < 0)
-		goto out_cfd;
-
-	ofd = accept(cfd, NULL, 0);
-	if (ofd < 0) {
-		ret = ofd;
-		goto out_cfd;
+	if (fstat(fd, &stbuff) < 0) {
+		fprintf(stderr, "Error doing fstat: %s\n", strerror(errno));
+		return -1;
 	}
-
-	ffd = open(object, O_RDONLY);
-	if (ffd < 0) {
-		fprintf(stderr, "Error opening object %s: %s\n",
-			object, strerror(errno));
-		ret = ffd;
-		goto out_ofd;
+	if ((size_t)stbuff.st_size != stbuff.st_size) {
+		fprintf(stderr, "Object %s is too big\n", object);
+		return -EFBIG;
 	}
-
-	ret = fstat(ffd, &stbuff);
-	if (ret < 0) {
-		fprintf(stderr, "Error doing fstat: %s\n",
+	data = mmap(NULL, stbuff.st_size, PROT_READ, MAP_SHARED, fd, 0);
+	if (data == MAP_FAILED) {
+		fprintf(stderr, "Error mapping object %s: %s\n", object,
 			strerror(errno));
-		goto out_ffd;
-	}
-
-	size = sendfile(ofd, ffd, NULL, stbuff.st_size);
-	if (size != stbuff.st_size) {
-		fprintf(stderr, "Error from sendfile (%zd vs %zu bytes): %s\n",
-			size, stbuff.st_size, strerror(errno));
-		ret = -1;
-		goto out_ffd;
+		return -1;
 	}
-
-	size = read(ofd, out, len);
-	if (size != len) {
-		fprintf(stderr, "Error from read (%zd vs %zu bytes): %s\n",
-			size, len, strerror(errno));
-		ret = -1;
-	} else {
-		ret = 0;
-	}
-out_ffd:
-	close(ffd);
-out_ofd:
-	close(ofd);
-out_cfd:
-	close(cfd);
-	return ret;
+	sha1(data, stbuff.st_size, out);
+	munmap(data, stbuff.st_size);
+	return 0;
 }
 
 static void bpf_init_env(void)
 {
 	struct rlimit limit = {
@@ -1812,16 +1768,10 @@ static int bpf_maps_attach_all(struct bpf_elf_ctx *ctx)
 {
 	int i, j, ret, fd, inner_fd, inner_idx, have_map_in_map = 0;
 	const char *map_name;
 
 	for (i = 0; i < ctx->map_num; i++) {
-		if (ctx->maps[i].pinning == PIN_OBJECT_NS &&
-		    ctx->noafalg) {
-			fprintf(stderr, "Missing kernel AF_ALG support for PIN_OBJECT_NS!\n");
-			return -ENOTSUP;
-		}
-
 		map_name = bpf_map_fetch_name(ctx, i);
 		if (!map_name)
 			return -EIO;
 
 		fd = bpf_map_attach(map_name, ctx, &ctx->maps[i],
@@ -2867,35 +2817,36 @@ static void bpf_get_cfg(struct bpf_elf_ctx *ctx)
 
 static int bpf_elf_ctx_init(struct bpf_elf_ctx *ctx, const char *pathname,
 			    enum bpf_prog_type type, __u32 ifindex,
 			    bool verbose)
 {
-	uint8_t tmp[20];
+	__u8 tmp[SHA1_DIGEST_SIZE];
 	int ret;
 
 	if (elf_version(EV_CURRENT) == EV_NONE)
 		return -EINVAL;
 
 	bpf_init_env();
 
 	memset(ctx, 0, sizeof(*ctx));
 	bpf_get_cfg(ctx);
 
-	ret = bpf_obj_hash(pathname, tmp, sizeof(tmp));
-	if (ret)
-		ctx->noafalg = true;
-	else
-		hexstring_n2a(tmp, sizeof(tmp), ctx->obj_uid,
-			      sizeof(ctx->obj_uid));
-
 	ctx->verbose = verbose;
 	ctx->type    = type;
 	ctx->ifindex = ifindex;
 
 	ctx->obj_fd = open(pathname, O_RDONLY);
-	if (ctx->obj_fd < 0)
+	if (ctx->obj_fd < 0) {
+		fprintf(stderr, "Error opening object %s: %s\n", pathname,
+			strerror(errno));
 		return ctx->obj_fd;
+	}
+
+	ret = bpf_obj_hash(ctx->obj_fd, pathname, tmp);
+	if (ret)
+		goto out_fd;
+	hexstring_n2a(tmp, sizeof(tmp), ctx->obj_uid, sizeof(ctx->obj_uid));
 
 	ctx->elf_fd = elf_begin(ctx->obj_fd, ELF_C_READ, NULL);
 	if (!ctx->elf_fd) {
 		ret = -EINVAL;
 		goto out_fd;
@@ -3257,16 +3208,10 @@ bool iproute2_is_pin_map(const char *libbpf_map_name, char *pathname)
 	const char *map_name, *tmp;
 	unsigned int pinning;
 	int i, ret = 0;
 
 	for (i = 0; i < ctx->map_num; i++) {
-		if (ctx->maps[i].pinning == PIN_OBJECT_NS &&
-		    ctx->noafalg) {
-			fprintf(stderr, "Missing kernel AF_ALG support for PIN_OBJECT_NS!\n");
-			return false;
-		}
-
 		map_name = bpf_map_fetch_name(ctx, i);
 		if (!map_name) {
 			return false;
 		}
 
diff --git a/lib/sha1.c b/lib/sha1.c
new file mode 100644
index 00000000..1aa8fd83
--- /dev/null
+++ b/lib/sha1.c
@@ -0,0 +1,108 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * SHA-1 message digest algorithm
+ *
+ * Copyright 2025 Google LLC
+ */
+
+#include <arpa/inet.h>
+#include <string.h>
+
+#include "sha1.h"
+#include "utils.h"
+
+static const __u32 sha1_K[4] = { 0x5A827999, 0x6ED9EBA1, 0x8F1BBCDC,
+				 0xCA62C1D6 };
+
+static inline __u32 rol32(__u32 v, int bits)
+{
+	return (v << bits) | (v >> (32 - bits));
+}
+
+#define round_up(a, b) (((a) + (b) - 1) & ~((b) - 1))
+
+#define SHA1_ROUND(i, a, b, c, d, e)                                           \
+	do {                                                                   \
+		if ((i) >= 16)                                                 \
+			w[i] = rol32(w[(i) - 16] ^ w[(i) - 14] ^ w[(i) - 8] ^  \
+					     w[(i) - 3],                       \
+				     1);                                       \
+		e += w[i] + rol32(a, 5) + sha1_K[(i) / 20];                    \
+		if ((i) < 20)                                                  \
+			e += (b & (c ^ d)) ^ d;                                \
+		else if ((i) < 40 || (i) >= 60)                                \
+			e += b ^ c ^ d;                                        \
+		else                                                           \
+			e += (c & d) ^ (b & (c ^ d));                          \
+		b = rol32(b, 30);                                              \
+		/* The new (a, b, c, d, e) is the old (e, a, b, c, d). */      \
+	} while (0)
+
+#define SHA1_5ROUNDS(i)                                                        \
+	do {                                                                   \
+		SHA1_ROUND((i) + 0, a, b, c, d, e);                            \
+		SHA1_ROUND((i) + 1, e, a, b, c, d);                            \
+		SHA1_ROUND((i) + 2, d, e, a, b, c);                            \
+		SHA1_ROUND((i) + 3, c, d, e, a, b);                            \
+		SHA1_ROUND((i) + 4, b, c, d, e, a);                            \
+	} while (0)
+
+#define SHA1_20ROUNDS(i)                                                       \
+	do {                                                                   \
+		SHA1_5ROUNDS((i) + 0);                                         \
+		SHA1_5ROUNDS((i) + 5);                                         \
+		SHA1_5ROUNDS((i) + 10);                                        \
+		SHA1_5ROUNDS((i) + 15);                                        \
+	} while (0)
+
+static void sha1_blocks(__u32 h[5], const __u8 *data, size_t nblocks)
+{
+	while (nblocks--) {
+		__u32 a = h[0];
+		__u32 b = h[1];
+		__u32 c = h[2];
+		__u32 d = h[3];
+		__u32 e = h[4];
+		__u32 w[80];
+		int i;
+
+		memcpy(w, data, SHA1_BLOCK_SIZE);
+		for (i = 0; i < 16; i++)
+			w[i] = ntohl(w[i]);
+		SHA1_20ROUNDS(0);
+		SHA1_20ROUNDS(20);
+		SHA1_20ROUNDS(40);
+		SHA1_20ROUNDS(60);
+
+		h[0] += a;
+		h[1] += b;
+		h[2] += c;
+		h[3] += d;
+		h[4] += e;
+		data += SHA1_BLOCK_SIZE;
+	}
+}
+
+/* Calculate the SHA-1 message digest of the given data. */
+void sha1(const __u8 *data, size_t len, __u8 out[SHA1_DIGEST_SIZE])
+{
+	__u32 h[5] = { 0x67452301, 0xEFCDAB89, 0x98BADCFE, 0x10325476,
+		       0xC3D2E1F0 };
+	const __be64 bitcount = htonll((__u64)len * 8);
+	__u8 final_data[2 * SHA1_BLOCK_SIZE] = { 0 };
+	size_t final_len = len % SHA1_BLOCK_SIZE;
+	int i;
+
+	sha1_blocks(h, data, len / SHA1_BLOCK_SIZE);
+
+	memcpy(final_data, data + len - final_len, final_len);
+	final_data[final_len] = 0x80;
+	final_len = round_up(final_len + 9, SHA1_BLOCK_SIZE);
+	memcpy(&final_data[final_len - 8], &bitcount, 8);
+
+	sha1_blocks(h, final_data, final_len / SHA1_BLOCK_SIZE);
+
+	for (i = 0; i < ARRAY_SIZE(h); i++)
+		h[i] = htonl(h[i]);
+	memcpy(out, h, SHA1_DIGEST_SIZE);
+}

base-commit: 1f7924938884235daa5594f1d0f18c5b07fa9d74
-- 
2.51.0

Re: [PATCH iproute2-next v2] lib/bpf_legacy: Use userspace SHA-1 code instead of AF_ALG

[Alexei Starovoitov]

On Mon, Sep 29, 2025 at 12:48 PM Eric Biggers <ebiggers@kernel.org> wrote:
>
> Add a basic SHA-1 implementation to lib/, and make lib/bpf_legacy.c use
> it to calculate SHA-1 digests instead of the previous AF_ALG-based code.
>
> This eliminates the dependency on AF_ALG, specifically the kernel config
> options CONFIG_CRYPTO_USER_API_HASH and CONFIG_CRYPTO_SHA1.
>
> Over the years AF_ALG has been very problematic, and it is also not
> supported on all kernels.  Escalating to the kernel's privileged
> execution context merely to calculate software algorithms, which can be
> done in userspace instead, is not something that should have ever been
> supported.  Even on kernels that support it, the syscall overhead of
> AF_ALG means that it is often slower than userspace code.

Help me understand the crusade against AF_ALG.
Do you want to deprecate AF_ALG altogether or when it's used for
sha-s like sha1 and sha256 ?

I thought the main advantage of going through the kernel is that
the kernel might have an optimized implementation for a specific
architecture, while the open coded C version is generic.
The cost of syscall and copies in/out is small compared
to actual math, especially since compilers might not be smart enough
to use single asm insn for rol32() C function.

sha1/256 are simple enough in plain C, but other crypto/hash
could be complex and the kernel may have HW acceleration for them.
CONFIG_CRYPTO_USER_API_HASH has been there forever and plenty
of projects have code to use that. Like qemu, stress-ng, ruby.
python and rust have standard binding for af_alg too.
If the kernel has optimized and/or hw accelerated crypto, I see an appeal
to alway use AF_ALG when it's available.

Re: [PATCH iproute2-next v2] lib/bpf_legacy: Use userspace SHA-1 code instead of AF_ALG

[Eric Biggers]

On Wed, Oct 01, 2025 at 03:59:31PM -0700, Alexei Starovoitov wrote:
> On Mon, Sep 29, 2025 at 12:48 PM Eric Biggers <ebiggers@kernel.org> wrote:
> >
> > Add a basic SHA-1 implementation to lib/, and make lib/bpf_legacy.c use
> > it to calculate SHA-1 digests instead of the previous AF_ALG-based code.
> >
> > This eliminates the dependency on AF_ALG, specifically the kernel config
> > options CONFIG_CRYPTO_USER_API_HASH and CONFIG_CRYPTO_SHA1.
> >
> > Over the years AF_ALG has been very problematic, and it is also not
> > supported on all kernels.  Escalating to the kernel's privileged
> > execution context merely to calculate software algorithms, which can be
> > done in userspace instead, is not something that should have ever been
> > supported.  Even on kernels that support it, the syscall overhead of
> > AF_ALG means that it is often slower than userspace code.
> 
> Help me understand the crusade against AF_ALG.
> Do you want to deprecate AF_ALG altogether or when it's used for
> sha-s like sha1 and sha256 ?

Altogether, when possible.  AF_ALG has been (and continues to be)
incredibly problematic, for both security and maintainability.

> I thought the main advantage of going through the kernel is that
> the kernel might have an optimized implementation for a specific
> architecture, while the open coded C version is generic.
> The cost of syscall and copies in/out is small compared
> to actual math, especially since compilers might not be smart enough
> to use single asm insn for rol32() C function.

Not for small amounts of data, since syscalls are expensive these days.

(Aren't BPF programs usually fairly small?)

BTW, both gcc and clang reliably lower rol32() to a single instruction.

> sha1/256 are simple enough in plain C, but other crypto/hash
> could be complex and the kernel may have HW acceleration for them.
> CONFIG_CRYPTO_USER_API_HASH has been there forever and plenty
> of projects have code to use that. Like qemu, stress-ng, ruby.
> python and rust have standard binding for af_alg too.
> If the kernel has optimized and/or hw accelerated crypto, I see an appeal
> to alway use AF_ALG when it's available.

Well, userspace programs that want accelerated crypto routines without
incorporating them themselves should just use a userspace library that
has them.  It's not hard.

But iproute2 should be fine with just the generic C code.

As for why AF_ALG support keeps showing up in different programs, it's
mainly just a misunderstanding.  But I think you're also overestimating
how often it's used.  Your 5 examples were 4 bindings (not users), and 1
user where it's disabled by default.

There are Linux systems where it's only iproute2 that's blocking
CONFIG_CRYPTO_USER_API_HASH from being disabled.  This patch is really
valuable on such systems.

- Eric

Re: [PATCH iproute2-next v2] lib/bpf_legacy: Use userspace SHA-1 code instead of AF_ALG

[Alexei Starovoitov]

On Wed, Oct 1, 2025 at 4:33 PM Eric Biggers <ebiggers@kernel.org> wrote:
>
> On Wed, Oct 01, 2025 at 03:59:31PM -0700, Alexei Starovoitov wrote:
> > On Mon, Sep 29, 2025 at 12:48 PM Eric Biggers <ebiggers@kernel.org> wrote:
> > >
> > > Add a basic SHA-1 implementation to lib/, and make lib/bpf_legacy.c use
> > > it to calculate SHA-1 digests instead of the previous AF_ALG-based code.
> > >
> > > This eliminates the dependency on AF_ALG, specifically the kernel config
> > > options CONFIG_CRYPTO_USER_API_HASH and CONFIG_CRYPTO_SHA1.
> > >
> > > Over the years AF_ALG has been very problematic, and it is also not
> > > supported on all kernels.  Escalating to the kernel's privileged
> > > execution context merely to calculate software algorithms, which can be
> > > done in userspace instead, is not something that should have ever been
> > > supported.  Even on kernels that support it, the syscall overhead of
> > > AF_ALG means that it is often slower than userspace code.
> >
> > Help me understand the crusade against AF_ALG.
> > Do you want to deprecate AF_ALG altogether or when it's used for
> > sha-s like sha1 and sha256 ?
>
> Altogether, when possible.  AF_ALG has been (and continues to be)
> incredibly problematic, for both security and maintainability.

Could you provide an example of a security issue with AF_ALG ?
Not challenging the statement. Mainly curious what is going
to understand it better and pass the message.

> > I thought the main advantage of going through the kernel is that
> > the kernel might have an optimized implementation for a specific
> > architecture, while the open coded C version is generic.
> > The cost of syscall and copies in/out is small compared
> > to actual math, especially since compilers might not be smart enough
> > to use single asm insn for rol32() C function.
>
> Not for small amounts of data, since syscalls are expensive these days.
>
> (Aren't BPF programs usually fairly small?)

Depends on the definition of small :)
The largest we have in production is 620kbytes of ELF.
Couple dozens between 100k to 400k.
And a hundred between 5k to 50k.

>
> BTW, both gcc and clang reliably lower rol32() to a single instruction.
>
> > sha1/256 are simple enough in plain C, but other crypto/hash
> > could be complex and the kernel may have HW acceleration for them.
> > CONFIG_CRYPTO_USER_API_HASH has been there forever and plenty
> > of projects have code to use that. Like qemu, stress-ng, ruby.
> > python and rust have standard binding for af_alg too.
> > If the kernel has optimized and/or hw accelerated crypto, I see an appeal
> > to alway use AF_ALG when it's available.
>
> Well, userspace programs that want accelerated crypto routines without
> incorporating them themselves should just use a userspace library that
> has them.  It's not hard.
>
> But iproute2 should be fine with just the generic C code.
>
> As for why AF_ALG support keeps showing up in different programs, it's
> mainly just a misunderstanding.  But I think you're also overestimating
> how often it's used.  Your 5 examples were 4 bindings (not users), and 1
> user where it's disabled by default.
>
> There are Linux systems where it's only iproute2 that's blocking
> CONFIG_CRYPTO_USER_API_HASH from being disabled.  This patch is really
> valuable on such systems.

Fair enough.

Re: [PATCH iproute2-next v2] lib/bpf_legacy: Use userspace SHA-1 code instead of AF_ALG

[Eric Biggers]

On Thu, Oct 02, 2025 at 10:12:12AM -0700, Alexei Starovoitov wrote:
> On Wed, Oct 1, 2025 at 4:33 PM Eric Biggers <ebiggers@kernel.org> wrote:
> >
> > On Wed, Oct 01, 2025 at 03:59:31PM -0700, Alexei Starovoitov wrote:
> > > On Mon, Sep 29, 2025 at 12:48 PM Eric Biggers <ebiggers@kernel.org> wrote:
> > > >
> > > > Add a basic SHA-1 implementation to lib/, and make lib/bpf_legacy.c use
> > > > it to calculate SHA-1 digests instead of the previous AF_ALG-based code.
> > > >
> > > > This eliminates the dependency on AF_ALG, specifically the kernel config
> > > > options CONFIG_CRYPTO_USER_API_HASH and CONFIG_CRYPTO_SHA1.
> > > >
> > > > Over the years AF_ALG has been very problematic, and it is also not
> > > > supported on all kernels.  Escalating to the kernel's privileged
> > > > execution context merely to calculate software algorithms, which can be
> > > > done in userspace instead, is not something that should have ever been
> > > > supported.  Even on kernels that support it, the syscall overhead of
> > > > AF_ALG means that it is often slower than userspace code.
> > >
> > > Help me understand the crusade against AF_ALG.
> > > Do you want to deprecate AF_ALG altogether or when it's used for
> > > sha-s like sha1 and sha256 ?
> >
> > Altogether, when possible.  AF_ALG has been (and continues to be)
> > incredibly problematic, for both security and maintainability.
> 
> Could you provide an example of a security issue with AF_ALG ?
> Not challenging the statement. Mainly curious what is going
> to understand it better and pass the message.

It's a gold mine for attackers looking to exploit the kernel.  Here are
some examples from the CVE list when searching for "AF_ALG":

https://nvd.nist.gov/vuln/detail/CVE-2025-38079

    In the Linux kernel, the following vulnerability has been resolved:
    crypto: algif_hash - fix double free in hash_accept If accept(2) is
    called on socket type algif_hash with MSG_MORE flag set and
    crypto_ahash_import fails, sk2 is freed. However, it is also freed
    in af_alg_release, leading to slab-use-after-free error.

https://nvd.nist.gov/vuln/detail/CVE-2025-37808

    In the Linux kernel, the following vulnerability has been resolved:
    crypto: null - Use spin lock instead of mutex As the null algorithm
    may be freed in softirq context through af_alg, use spin locks
    instead of mutexes to protect the default null algorithm. 

https://nvd.nist.gov/vuln/detail/CVE-2024-26824

    In the Linux kernel, the following vulnerability has been resolved:
    crypto: algif_hash - Remove bogus SGL free on zero-length error path
    When a zero-length message is hashed by algif_hash, and an error is
    triggered, it tries to free an SG list that was never allocated in
    the first place. Fix this by not freeing the SG list on the
    zero-length error path.

https://nvd.nist.gov/vuln/detail/CVE-2022-48781

    In the Linux kernel, the following vulnerability has been resolved:
    crypto: af_alg - get rid of alg_memory_allocated
    alg_memory_allocated does not seem to be really used. alg_proto does
    have a .memory_allocated field, but no corresponding .sysctl_mem.
    This means sk_has_account() returns true, but all
    sk_prot_mem_limits() users will trigger a NULL dereference

https://nvd.nist.gov/vuln/detail/CVE-2019-8912

    n the Linux kernel through 4.20.11, af_alg_release() in
    crypto/af_alg.c neglects to set a NULL value for a certain structure
    member, which leads to a use-after-free in sockfs_setattr.

https://nvd.nist.gov/vuln/detail/CVE-2018-14619

    A flaw was found in the crypto subsystem of the Linux kernel before
    version kernel-4.15-rc4. The "null skcipher" was being dropped when
    each af_alg_ctx was freed instead of when the aead_tfm was freed.
    This can cause the null skcipher to be freed while it is still in
    use leading to a local user being able to crash the system or
    possibly escalate privileges. 

https://nvd.nist.gov/vuln/detail/CVE-2017-18075

    crypto/pcrypt.c in the Linux kernel before 4.14.13 mishandles
    freeing instances, allowing a local user able to access the
    AF_ALG-based AEAD interface (CONFIG_CRYPTO_USER_API_AEAD) and pcrypt
    (CONFIG_CRYPTO_PCRYPT) to cause a denial of service (kfree of an
    incorrect pointer) or possibly have unspecified other impact by
    executing a crafted sequence of system calls. 

https://nvd.nist.gov/vuln/detail/CVE-2017-17806

    The HMAC implementation (crypto/hmac.c) in the Linux kernel before
    4.14.8 does not validate that the underlying cryptographic hash
    algorithm is unkeyed, allowing a local attacker able to use the
    AF_ALG-based hash interface (CONFIG_CRYPTO_USER_API_HASH) and the
    SHA-3 hash algorithm (CONFIG_CRYPTO_SHA3) to cause a kernel stack
    buffer overflow by executing a crafted sequence of system calls that
    encounter a missing SHA-3 initialization.

https://nvd.nist.gov/vuln/detail/CVE-2017-17805

    The Salsa20 encryption algorithm in the Linux kernel before 4.14.8
    does not correctly handle zero-length inputs, allowing a local
    attacker able to use the AF_ALG-based skcipher interface
    (CONFIG_CRYPTO_USER_API_SKCIPHER) to cause a denial of service
    (uninitialized-memory free and kernel crash) or have unspecified
    other impact by executing a crafted sequence of system calls that
    use the blkcipher_walk API. Both the generic implementation
    (crypto/salsa20_generic.c) and x86 implementation
    (arch/x86/crypto/salsa20_glue.c) of Salsa20 were vulnerable. 

https://nvd.nist.gov/vuln/detail/CVE-2016-10147

    crypto/mcryptd.c in the Linux kernel before 4.8.15 allows local
    users to cause a denial of service (NULL pointer dereference and
    system crash) by using an AF_ALG socket with an incompatible
    algorithm, as demonstrated by mcryptd(md5).

https://nvd.nist.gov/vuln/detail/CVE-2015-8970

    crypto/algif_skcipher.c in the Linux kernel before 4.4.2 does not
    verify that a setkey operation has been performed on an AF_ALG
    socket before an accept system call is processed, which allows local
    users to cause a denial of service (NULL pointer dereference and
    system crash) via a crafted application that does not supply a key,
    related to the lrw_crypt function in crypto/lrw.c.

https://nvd.nist.gov/vuln/detail/CVE-2015-3331

    The __driver_rfc4106_decrypt function in
    arch/x86/crypto/aesni-intel_glue.c in the Linux kernel before 3.19.3
    does not properly determine the memory locations used for encrypted
    data, which allows context-dependent attackers to cause a denial of
    service (buffer overflow and system crash) or possibly execute
    arbitrary code by triggering a crypto API call, as demonstrated by
    use of a libkcapi test program with an AF_ALG(aead) socket.

https://nvd.nist.gov/vuln/detail/CVE-2014-9644

    The Crypto API in the Linux kernel before 3.18.5 allows local users
    to load arbitrary kernel modules via a bind system call for an
    AF_ALG socket with a parenthesized module template expression in the
    salg_name field, as demonstrated by the vfat(aes) expression, a
    different vulnerability than CVE-2013-7421.

https://nvd.nist.gov/vuln/detail/CVE-2013-7421

    The Crypto API in the Linux kernel before 3.18.5 allows local users
    to load arbitrary kernel modules via a bind system call for an
    AF_ALG socket with a module name in the salg_name field, a different
    vulnerability than CVE-2014-9644.

https://nvd.nist.gov/vuln/detail/CVE-2011-4081

    crypto/ghash-generic.c in the Linux kernel before 3.1 allows local
    users to cause a denial of service (NULL pointer dereference and
    OOPS) or possibly have unspecified other impact by triggering a
    failed or missing ghash_setkey function call, followed by a (1)
    ghash_update function call or (2) ghash_final function call, as
    demonstrated by a write operation on an AF_ALG socket.

- Eric

Re: [PATCH iproute2-next v2] lib/bpf_legacy: Use userspace SHA-1 code instead of AF_ALG

[Alexei Starovoitov]

On Thu, Oct 2, 2025 at 10:37 AM Eric Biggers <ebiggers@kernel.org> wrote:
>
> On Thu, Oct 02, 2025 at 10:12:12AM -0700, Alexei Starovoitov wrote:
> > On Wed, Oct 1, 2025 at 4:33 PM Eric Biggers <ebiggers@kernel.org> wrote:
> > >
> > > On Wed, Oct 01, 2025 at 03:59:31PM -0700, Alexei Starovoitov wrote:
> > > > On Mon, Sep 29, 2025 at 12:48 PM Eric Biggers <ebiggers@kernel.org> wrote:
> > > > >
> > > > > Add a basic SHA-1 implementation to lib/, and make lib/bpf_legacy.c use
> > > > > it to calculate SHA-1 digests instead of the previous AF_ALG-based code.
> > > > >
> > > > > This eliminates the dependency on AF_ALG, specifically the kernel config
> > > > > options CONFIG_CRYPTO_USER_API_HASH and CONFIG_CRYPTO_SHA1.
> > > > >
> > > > > Over the years AF_ALG has been very problematic, and it is also not
> > > > > supported on all kernels.  Escalating to the kernel's privileged
> > > > > execution context merely to calculate software algorithms, which can be
> > > > > done in userspace instead, is not something that should have ever been
> > > > > supported.  Even on kernels that support it, the syscall overhead of
> > > > > AF_ALG means that it is often slower than userspace code.
> > > >
> > > > Help me understand the crusade against AF_ALG.
> > > > Do you want to deprecate AF_ALG altogether or when it's used for
> > > > sha-s like sha1 and sha256 ?
> > >
> > > Altogether, when possible.  AF_ALG has been (and continues to be)
> > > incredibly problematic, for both security and maintainability.
> >
> > Could you provide an example of a security issue with AF_ALG ?
> > Not challenging the statement. Mainly curious what is going
> > to understand it better and pass the message.
>
> It's a gold mine for attackers looking to exploit the kernel.  Here are
> some examples from the CVE list when searching for "AF_ALG":

Ohh. I see. That made it very concrete. Thanks!

Acked-by: Alexei Starovoitov <ast@kernel.org>

Re: [PATCH iproute2-next v2] lib/bpf_legacy: Use userspace SHA-1 code instead of AF_ALG

[Eric Biggers]

[Adding David Ahern.  I overlooked that iproute2 has separate
maintainers for the main tree and the next tree.]

On Mon, Sep 29, 2025 at 12:46:48PM -0700, Eric Biggers wrote:
> Add a basic SHA-1 implementation to lib/, and make lib/bpf_legacy.c use
> it to calculate SHA-1 digests instead of the previous AF_ALG-based code.
> 
> This eliminates the dependency on AF_ALG, specifically the kernel config
> options CONFIG_CRYPTO_USER_API_HASH and CONFIG_CRYPTO_SHA1.
> 
> Over the years AF_ALG has been very problematic, and it is also not
> supported on all kernels.  Escalating to the kernel's privileged
> execution context merely to calculate software algorithms, which can be
> done in userspace instead, is not something that should have ever been
> supported.  Even on kernels that support it, the syscall overhead of
> AF_ALG means that it is often slower than userspace code.
> 
> Let's do the right thing here, and allow people to disable AF_ALG
> support (or not enable it) on systems where iproute2 is the only user.
> 
> Acked-by: Ard Biesheuvel <ardb@kernel.org>
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>

Stephen and David, any interest in applying this patch?

- Eric

Re: [PATCH iproute2-next v2] lib/bpf_legacy: Use userspace SHA-1 code instead of AF_ALG

[Stephen Hemminger]

On Mon, 29 Sep 2025 12:46:48 -0700
Eric Biggers <ebiggers@kernel.org> wrote:

> diff --git a/lib/sha1.c b/lib/sha1.c
> new file mode 100644
> index 00000000..1aa8fd83
> --- /dev/null
> +++ b/lib/sha1.c
> @@ -0,0 +1,108 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * SHA-1 message digest algorithm
> + *
> + * Copyright 2025 Google LLC
> + */

Not a big fan of having actual crypto in iproute2.
It creates even more technical debt.
Is there another crypto library that could be used?


Better yet, is there a reason legacy BPF code needs to still exist
in current iproute2? When was the cut over.

Re: [PATCH iproute2-next v2] lib/bpf_legacy: Use userspace SHA-1 code instead of AF_ALG

[Eric Biggers]

On Wed, Nov 12, 2025 at 12:12:12PM -0800, Stephen Hemminger wrote:
> On Mon, 29 Sep 2025 12:46:48 -0700
> Eric Biggers <ebiggers@kernel.org> wrote:
> 
> > diff --git a/lib/sha1.c b/lib/sha1.c
> > new file mode 100644
> > index 00000000..1aa8fd83
> > --- /dev/null
> > +++ b/lib/sha1.c
> > @@ -0,0 +1,108 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * SHA-1 message digest algorithm
> > + *
> > + * Copyright 2025 Google LLC
> > + */
> 
> Not a big fan of having actual crypto in iproute2.
> It creates even more technical debt.
> Is there another crypto library that could be used?

Currently iproute2 doesn't depend on OpenSSL.  You can make it do that,
if you want, and then you could use SHA-1 from there.  I suspect that
doing that would be much more trouble than just adding this SHA-1 code.

If you happen to be planning to pull in OpenSSL as a dependency for
other reasons, it might make sense then.

> Better yet, is there a reason legacy BPF code needs to still exist
> in current iproute2? When was the cut over.

No idea.  That's a question for the BPF folks.

- Eric

Re: [PATCH iproute2-next v2] lib/bpf_legacy: Use userspace SHA-1 code instead of AF_ALG

[Ard Biesheuvel]

On Wed, 12 Nov 2025 at 21:12, Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> On Mon, 29 Sep 2025 12:46:48 -0700
> Eric Biggers <ebiggers@kernel.org> wrote:
>
> > diff --git a/lib/sha1.c b/lib/sha1.c
> > new file mode 100644
> > index 00000000..1aa8fd83
> > --- /dev/null
> > +++ b/lib/sha1.c
> > @@ -0,0 +1,108 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * SHA-1 message digest algorithm
> > + *
> > + * Copyright 2025 Google LLC
> > + */
>
> Not a big fan of having actual crypto in iproute2.
> It creates even more technical debt.

I understand your position, and I agree with it in principle.

However, the usual motivation for not re-inventing/re-implementing
your own crypto is the risk associated with getting it wrong, or with
failing to keep up with bug fixes etc. Given that SHA-1 is already
considered broken beyond repair for its original purpose, and is now
merely a glorified checksumming algorithm that is only kept around to
retain backward compatibility, I'd argue that the situation is a bit
different here.

Also, I strongly agree with Eric that a syscall interface to perform
crypto s/w arithmetic that could easily execute in user space is
something that should have never been added, and creates portability
concerns for no good reason.

Re: [PATCH iproute2-next v2] lib/bpf_legacy: Use userspace SHA-1 code instead of AF_ALG

[Simon Richter]

Hi,

On 11/13/25 4:25 PM, Ard Biesheuvel wrote:

> Also, I strongly agree with Eric that a syscall interface to perform
> crypto s/w arithmetic that could easily execute in user space is
> something that should have never been added, and creates portability
> concerns for no good reason.

Would it make sense to add crypto (and other transform) operations to 
the vdso, and make the decision whether the syscall is beneficial from 
there, depending on request/batch size (speed vs overhead tradeoff), 
data source/sink and available hardware?

For example, "gzip -d" pulling data from a file and writing to a file 
will need to transfer the data to userspace first, process it there, 
then transfer it back to kernelspace so it can be written to a file.

That's a lot of syscall and transfer overhead compared to just a single 
"decompress this file" call that keeps the data entirely in kernelspace 
-- so we benefit already even if there is no hardware gzip decompressor, 
and users that have one (such as myself) would benefit even further.

    Simon

Re: [PATCH iproute2-next v2] lib/bpf_legacy: Use userspace SHA-1 code instead of AF_ALG

[Ard Biesheuvel]

On Thu, 13 Nov 2025 at 09:51, Simon Richter <Simon.Richter@hogyros.de> wrote:
>
> Hi,
>
> On 11/13/25 4:25 PM, Ard Biesheuvel wrote:
>
> > Also, I strongly agree with Eric that a syscall interface to perform
> > crypto s/w arithmetic that could easily execute in user space is
> > something that should have never been added, and creates portability
> > concerns for no good reason.
>
> Would it make sense to add crypto (and other transform) operations to
> the vdso, and make the decision whether the syscall is beneficial from
> there, depending on request/batch size (speed vs overhead tradeoff),
> data source/sink and available hardware?
>

No. User space has all the tools it needs to make his determination
itself, and OpenSSL (for example) already supports the 'afalg' engine,
which will use AF_ALG, but transparently fall back to software crypto
if the engine does not support the algorithm in question. So there is
prior art, and therefore no need to complicate the kernel for this.

Note that taking the SHA-1 of a BPF program is guaranteed to be way
below the threshold of being worth the overhead of using a crypto
offload engine, so in the context of this thread, it is kind of a moot
point.

> For example, "gzip -d" pulling data from a file and writing to a file
> will need to transfer the data to userspace first, process it there,
> then transfer it back to kernelspace so it can be written to a file.
>

That is a different matter, and AF_ALG does not really help here at
all. The crypto equivalent of what you describe already exists in
fscrypt, which can transparently encrypt files, making use of
whichever flavor of crypto is available, including inline crypto,
where the h/w accelerator is in the storage controller, and not in a
separate IP block. I'm not a file system expert, but AFAIK, some file
systems already support compression at the file level as well, in
which case h/w offload will be used where available, and the
compressed data never travels to user space.

Similarly, on the networking side, there are things like VPN
acceleration and kTLS, where the crypto offload is combined with the
networking hardware.

Discrete crypto offload hardware is simply not something that has a
lot of good use cases anymore.

Re: [PATCH iproute2-next v2] lib/bpf_legacy: Use userspace SHA-1 code instead of AF_ALG

[David Ahern]

On 11/11/25 9:07 PM, Eric Biggers wrote:
> [Adding David Ahern.  I overlooked that iproute2 has separate
> maintainers for the main tree and the next tree.]
> 
> On Mon, Sep 29, 2025 at 12:46:48PM -0700, Eric Biggers wrote:
>> Add a basic SHA-1 implementation to lib/, and make lib/bpf_legacy.c use
>> it to calculate SHA-1 digests instead of the previous AF_ALG-based code.
>>
>> This eliminates the dependency on AF_ALG, specifically the kernel config
>> options CONFIG_CRYPTO_USER_API_HASH and CONFIG_CRYPTO_SHA1.
>>
>> Over the years AF_ALG has been very problematic, and it is also not
>> supported on all kernels.  Escalating to the kernel's privileged
>> execution context merely to calculate software algorithms, which can be
>> done in userspace instead, is not something that should have ever been
>> supported.  Even on kernels that support it, the syscall overhead of
>> AF_ALG means that it is often slower than userspace code.
>>
>> Let's do the right thing here, and allow people to disable AF_ALG
>> support (or not enable it) on systems where iproute2 is the only user.
>>
>> Acked-by: Ard Biesheuvel <ardb@kernel.org>
>> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> 
> Stephen and David, any interest in applying this patch?
> 
> - Eric

I do not have a strong opinion in either direction.

If we are going to entertain removing AF_ALG code, we should apply the
patch to iproute2-next at the beginning of a dev cycle to give maximum
time for testing before it rolls out.

Re: [PATCH iproute2-next v2] lib/bpf_legacy: Use userspace SHA-1 code instead of AF_ALG

[Eric Biggers]

On Sun, Nov 16, 2025 at 10:45:47AM -0700, David Ahern wrote:
> On 11/11/25 9:07 PM, Eric Biggers wrote:
> > [Adding David Ahern.  I overlooked that iproute2 has separate
> > maintainers for the main tree and the next tree.]
> > 
> > On Mon, Sep 29, 2025 at 12:46:48PM -0700, Eric Biggers wrote:
> >> Add a basic SHA-1 implementation to lib/, and make lib/bpf_legacy.c use
> >> it to calculate SHA-1 digests instead of the previous AF_ALG-based code.
> >>
> >> This eliminates the dependency on AF_ALG, specifically the kernel config
> >> options CONFIG_CRYPTO_USER_API_HASH and CONFIG_CRYPTO_SHA1.
> >>
> >> Over the years AF_ALG has been very problematic, and it is also not
> >> supported on all kernels.  Escalating to the kernel's privileged
> >> execution context merely to calculate software algorithms, which can be
> >> done in userspace instead, is not something that should have ever been
> >> supported.  Even on kernels that support it, the syscall overhead of
> >> AF_ALG means that it is often slower than userspace code.
> >>
> >> Let's do the right thing here, and allow people to disable AF_ALG
> >> support (or not enable it) on systems where iproute2 is the only user.
> >>
> >> Acked-by: Ard Biesheuvel <ardb@kernel.org>
> >> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> > 
> > Stephen and David, any interest in applying this patch?
> > 
> > - Eric
> 
> I do not have a strong opinion in either direction.
> 
> If we are going to entertain removing AF_ALG code, we should apply the
> patch to iproute2-next at the beginning of a dev cycle to give maximum
> time for testing before it rolls out.

Any insight into when that would be?

- Eric

Re: [PATCH iproute2-next v2] lib/bpf_legacy: Use userspace SHA-1 code instead of AF_ALG

[David Ahern]

On 12/17/25 4:44 PM, Eric Biggers wrote:
>> If we are going to entertain removing AF_ALG code, we should apply the
>> patch to iproute2-next at the beginning of a dev cycle to give maximum
>> time for testing before it rolls out.
> 
> Any insight into when that would be?
> 


re-send it now.