Re: [PATCH 2/3] AF_ALG: Drop support for off-CPU cryptography

[Dominique Martinet]

Harald Freudenberger wrote on Wed, Jun 03, 2026 at 03:33:12PM +0200:
> > AF_ALG is deprecated and exposed to unprivileged userspace.  Only
> > use the least buggy algorithm implementations: the pure software ones.
> >
> 
> I thought AF_ALG is marked as deprecated but still usable. This patch
> now actively disables groups of crypto implementations. Also it just
> assumes that all algorithms which are asynchronously implemented or
> do not have a fallback are to be disabled via AF_ALG.
> 
> There are may reasons for not having a synchronous implementation. For
> example if you need to fetch (asynch) some information from a HSM before
> doing the job of the algorithm. Also all secure key operations can't
> by definition run directly on the CPU but need to be fed into some
> hardware. Same is true with just acceleration - and acceleration via
> special hardware (crypto hw, or AI hardware for example) is very common
> on platforms priced by CPU cycles.
> 
> I also can't find any arguments for the statement 'Hardware accelerator
> drivers are frequently buggy.' Does this mean that the linux kernel
> from now on will not accept any hardware accelerator drivers any more?
> Statements about code quality should be addressed to the driver
> maintainer but not lead to tagging of groups of drivers.
> 
> I can understand that the AF_ALG shall be deprecated and fade away.
> But this patch out of the sudden disables the long standing AF_ALG
> interface at least for testing purpose and causes some failures in
> the s390 crypto test area without any chance to react at all.

I've also stumbled upon this for our embedded use case: we use CAAM
"blob" keys on NXP socs (specifically i.MX8MP and i.MX8ULP at least),
which pretty much requires af_alg, because the key material is just not
available: it's not a matter of performance (we actually only
encrypt/decrypt a few KB that will be used for LUKS key or similar), the
hardware is required to perform the operation, and the only API
available is through the kernel afaik.

The tool source is available here:
https://github.com/nxp-imx/crypto_af_alg
(which now fails with:
bind(3, {sa_family=AF_ALG, salg_type="skcipher", salg_feat=0, salg_mask=0, salg_name="tk(cbc(aes))"}, 88) = -1 ENOENT (No such file or directory)
)


I don't particularily care for the API used as long as we can keep using
the hardware key, but as far as I can see there's no alternative API --
what's the path forward?

Short term would it make sense to re-enable and make it a sysctl knob
like af_alg_restrict[1]?
[1] https://lore.kernel.org/linux-crypto/20260622234803.6982-1-ebiggers@xxxxxxxxxx/T/#u

Longer term we don't need many algorithm (the tool only supports
AES-256-CBC), so a much simpler API would do, but some replacement would
be greatly appreciated.. Embedded being embedded we can always kludge
something in, but I'd rather not fall back to that.


(I also second this felt sudden, I only noticed because the sysctl knob
made noise on fedora lists and I wanted to try, and it didn't
cherry-pick cleanly without this patch so that made me try, but I
probably wouldn't have noticed until much later otherwise...)


Thanks,
-- 
Dominique Martinet | Asmadeus