On Wed, Oct 1, 2025 at 4:33 PM Eric Biggers [off-list ref] wrote:
On Wed, Oct 01, 2025 at 03:59:31PM -0700, Alexei Starovoitov wrote:
quoted
On Mon, Sep 29, 2025 at 12:48 PM Eric Biggers [off-list ref] wrote:
quoted
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.
quoted
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.
quoted
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.