On Thu, Oct 2, 2025 at 10:37 AM Eric Biggers [off-list ref] wrote:
On Thu, Oct 02, 2025 at 10:12:12AM -0700, Alexei Starovoitov wrote:
quoted
On Wed, Oct 1, 2025 at 4:33 PM Eric Biggers [off-list ref] wrote:
quoted
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.
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>