lkml.org 
[lkml]   [2026]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: AF_ALG hardening
From
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.

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.

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"?

Simon

[1]
https://lore.kernel.org/linux-crypto/112bf0af-1551-4d3e-ab15-e5dea3fc2435@app.fastmail.com/

[2]
https://lore.kernel.org/linux-crypto/20260430011544.31823-1-ebiggers@kernel.org/
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2026-05-04 21:03    [W:0.082 / U:14.150 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and my Meterkast|Read the blog