On 10/05/2026 17:32, Eric Biggers wrote:

On Sun, May 10, 2026 at 08:54:07AM -0700, Kamran Khan wrote:

quoted

Hi,

AF_ALG is useful not just for hardware-offloading, but also for memory
isolation so that applications only get oracle access to the crypto keys and
a memory-safety vulnerability in user applications would not immediately put
the secret key material at risk.

Note that if that memory-safety vulnerability leads to code execution in
the application, then it doesn't matter that it "only" has oracle
access.  It can still decrypt any data encrypted by that key.

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.

The relevant threat model would be arbitrary reads, not any
"memory-safety vulnerability".

quoted

I understand and appreciate the concern with complex attack surface and the
increased frequency of attacks in this area. But I fear that completely
removing AF_ALG increases the risk for userspace applications relying on it
for memory isolation.

What alternatives do userspace applications have on Linux for ensuring
crypto keys are not exposed in user memory? That is, FreeBSD and NetBSD
natively provide /dev/crypto; removing AF_ALG would kill the only equivalent
option on the Linux side for kernel-delegated cryptography.

The standard solution is simply to use an isolated userspace process
like ssh-agent.  Yes, the keys will be in "user memory".  But "not
exposed in user memory" is *not* a correct statement of the problem.

(Also note that protecting not-actively-in-use data from arbitrary read
primitives doesn't require cryptography at all.  That can be done simply
by using mprotect() to remove read permission from the memory, then
temporarily adding it back when it needs to be accessed.)

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.

be worth spending some time researching what has been going on.

- Eric

Ignat