On Mon, Sep 29, 2025 at 12:48 PM Eric Biggers [off-list ref] 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.