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

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAADnVQKKQEjZjz21e_639XkttoT4NvXYxUb8oTQ4X7hZKYLduQ@mail.gmail.com>
Date: Wed, 1 Oct 2025 15:59:31 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Eric Biggers <ebiggers@...nel.org>
Cc: Network Development <netdev@...r.kernel.org>, Stephen Hemminger <stephen@...workplumber.org>, 
	bpf <bpf@...r.kernel.org>, 
	Linux Crypto Mailing List <linux-crypto@...r.kernel.org>, Ard Biesheuvel <ardb@...nel.org>
Subject: Re: [PATCH iproute2-next v2] lib/bpf_legacy: Use userspace SHA-1 code
 instead of AF_ALG

On Mon, Sep 29, 2025 at 12:48 PM Eric Biggers <ebiggers@...nel.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.