Re: AF_ALG hardening

[Simon Richter <Simon.Richter@hogyros.de>]

[-- Attachment #1.1: Type: text/plain, Size: 1823 bytes --]

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/

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]