Re: [PATCH] crypto: af_alg - Document the deprecation of AF_ALG

[Jeff Barnes <jeffbarnes@linux.microsoft.com>]

On May 12 2026, at 5:18 pm, Ignat Korchagin <ignat@linux.win> wrote:

> On Mon, May 11, 2026 at 10:38 PM Eric Biggers <ebiggers@kernel.org> wrote:
>>  
>> On Mon, May 11, 2026 at 10:03:21PM +0100, Ignat Korchagin wrote:
>> > I don't think fully discounting hardware offloading is beneficial
>> here. HW
>> > accelerators will be produced and without a common interface
>> vendors would
>> > start implementing their own "bespoke" drivers with bespoke userspace
>> > interfaces (we already had such proposals), which in turn may
>> introduce more
>> > attack surface. Yes, AF_ALG needs substantial improvement, but at
>> least it
>> > can be a standardisation point.
>>  
>> That isn't the best way to accelerate symmetric crypto anymore though,
>> if it ever was.  This has been known for a long time.
>>  
>> > > In any case, any hypothetical security benefit provided by AF_ALG would
>> > > have to be *very high* to outweigh the continuous stream of
>> > > vulnerabilities in it.  I understand that people using AF_ALG
>> might not
>> > > be familiar with that continuous stream of vulnerabilities, but
>> it would
>> >
>> >
>> > Is it actually that much compared to other features/subsystems,
>> like eBPF or
>> > user namespaces? But we don't rush to deprecate those - instead
>> trying to
>> > harden them and come up with better design.
>>  
>> There are plenty of other kernel features with a large attack surface,
>> of course.  But they tend to be much more useful than AF_ALG.  It's all
>> about weighing benefits vs. risks.
>  
> If divide number of CVEs in such systems on imaginary units of
> usefulness, I think the ratio is similar.
>  
>> When we get the point where a large number of Linux users *had* to
>> disable AF_ALG as an emergency vulnerability response, and at the same
>> time their systems weren't even using AF_ALG so nothing even broke and
>> they could have just done that to begin with, I think we get a very
>  
> Well, there were: cryptsetup, RHEL fips check, so there are some...

cryptsetup does not have a hard dependency on AF_ALG.
It is a potential consumer via AF_ALG.

AF_ALG provides a broad, hard-to-control interface
cryptsetup (and similar tools) are not blockers

AF_ALG removal does not necessarily break cryptsetup usage. Removal does
improve FIPS boundary clarity.


>  
>> clear idea of which side is heavier for AF_ALG in the real world.
>  
> Same thing could be said for unprivileged user namespaces - distros
> even put a custom sysctl to restrict it and no-one noticed.
>  
>> The main relevance of AF_ALG to the Linux community is that it allows
>> their systems to be exploited.
>  
> To be clear I'm not arguing for the current AF_ALG implementation. I
> agree, the splice zero-copy is... suboptimal (to be soft) and is
> actually not-so-zero copy. But I think it was just added before we had
> more modern approaches like io_uring (have their own can of worms, but
> hey - people adopt it fast).
>  
> But I advocate for the usefulness of the concept itself - kernel/OS
> providing crypto services to userspace. As mentioned in other threads,
> other operating systems have it and Linux lags behind. There are use
> cases: common interface for HW accelerators, embedded systems, which
> don't have the space to bring a userspace lib etc. Even non-technical:
> there are environments that just don't want to rely on third-party
> userspace libraries like OpenSSL purely for licensing reasons. And I
> agree, that it is hard to do it right, but we can piggy-back on other
> subsystems (such as io_uring mentioned or other ideas).
>  
>> - Eric
>>  
>  
> Ignat
>  
Jeff