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.

quoted

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.

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
clear idea of which side is heavier for AF_ALG in the real world.

The main relevance of AF_ALG to the Linux community is that it allows
their systems to be exploited.

- Eric