Re: AF_ALG hardening

[Eric Biggers]

On Tue, May 05, 2026 at 04:01:47AM +0900, Simon Richter wrote:
> Hi,
> 
> On 5/3/26 04:16, Eric Biggers wrote:
> 
> > On Sat, May 02, 2026 at 12:52:57AM -0400, Demi Marie Obenour wrote:
> 
> > > The simplest changes I can see are:
> 
> > > 1. Get rid of zero-copy support (splice()).
> > > 2. Get rid of AIO support.
> > > 3. Only allow software implementations.
> 
> > For (2) and (3), you can find examples of disabling asynchronous crypto
> 
> I think we need to make up our minds here.
> 
> This thread is about removing asynchronous implementations and accelerator
> support from AF_ALG, so it can support legacy applications with known-good
> implementations, while the other thread[1] is about removing everything
> *but* accelerator support from AF_ALG -- and as accelerators are typically
> asynchronous, this aspect has to stay as well.
> 

Thread [1] is a patch that removes the kernel's last
architecture-optimized implementation of MD5, which is a broken and
deprecated algorithm anyway.  So it's not just AF_ALG that's motivating
that particular patch, but also a desire to focus effort on modern
algorithms and keep the different Linux architectures consistent.  So I
think the scope of that thread is more narrow than what you're claiming.

Also, it's already been established that for now AF_ALG will have to
keep the software code used by a small set of userspace programs such as
iwd.  So no, it cannot be completely removed yet (except on systems that
don't use any of these programs, where it can be already).  However,
that doesn't mean that we shouldn't be nudging people towards better
solutions, with an eye towards future attack surface reductions.

> At least with the opposite proposals, it would be good to know which one is
> official policy.
> 
> At the same time, the third thread[2] deprecates AF_ALG because of its wonky
> security posture, while newer accelerators are implementing their own
> userspace interfaces because AF_ALG is too limited, so we're already
> replacing one CVE magnet with several independent ones, and deprecating
> AF_ALG means that future drivers will add even more of those because there
> is no longer a common framework to attach to.

It's long been clear that by far the best way to accelerate symmetric
crypto is to just put it in the CPU, or in-line in the storage or
network controller.  Indeed, that's what almost everyone does now.

So I would expect the demand for this kind of interface to symmetric
crypto to continue to decline, as it already has been for a long time.
And as you pointed out, AF_ALG doesn't work well for it anyway, which
makes AF_ALG increasingly kind of besides the point.

> Also, if AF_ALG is deprecated and the kernel no longer uses
> ahash/acrypt/acomp internally, there is no point in accelerator cards even
> registering with the crypto subsystem. Should that be an explicit policy
> "accelerator cards are outside the scope of the crypto subsystem, even if
> they implement a cryptographic algorithm"?

There are still some in-kernel users of the asynchronous crypto APIs,
for example IPsec and dm-crypt.  So I think your prediction of the
demise of these APIs is a bit premature as well.  But yes, at least for
the symmetric crypto, kernel subsystems have been been repeatedly seeing
that the async support just isn't worth it.  We'll see more kernel
subsystems switching to sync-only.  But in practice this is a gradual
transition.

Anyway, I don't think I'm proposing conflicting things.  We can and
should document a general deprecation of AF_ALG, while also helping
update userspace programs to no longer use it, while also applying
various hardening measures to reduce AF_ALG's attack surface as best we
can in the meantime.  There are multiple independent hardening measures
that could be applied, and they will be up for discussion on the
individual patches that implement them.

- Eric