From: Eric Biggers <ebiggers@kernel.org>
To: Kamran Khan <kz@inspirated.com>
Cc: Jeff Barnes <jeffbarnes@linux.microsoft.com>,
Andy Lutomirski <luto@amacapital.net>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
Herbert Xu <herbert@gondor.apana.org.au>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH] crypto: af_alg - Document the deprecation of AF_ALG
Date: Sun, 10 May 2026 09:32:04 -0700 [thread overview]
Message-ID: <20260510163204.GA2279@sol> (raw)
In-Reply-To: <0b8bba44-f6bb-4d69-b9d4-5787c276d41a@inspirated.com>
On Sun, May 10, 2026 at 08:54:07AM -0700, Kamran Khan wrote:
> 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.
The relevant threat model would be arbitrary reads, not any
"memory-safety vulnerability".
> 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
be worth spending some time researching what has been going on.
- Eric
next prev parent reply other threads:[~2026-05-10 16:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-30 1:15 [PATCH] crypto: af_alg - Document the deprecation of AF_ALG Eric Biggers
2026-04-30 2:05 ` Herbert Xu
2026-04-30 2:10 ` Eric Biggers
2026-05-04 14:39 ` Jon Kohler
2026-05-04 17:39 ` Eric Biggers
2026-05-04 18:12 ` Jeff Barnes
2026-05-04 18:24 ` Eric Biggers
2026-05-04 18:27 ` Simo Sorce
2026-05-04 17:41 ` Jeff Barnes
2026-05-05 9:31 ` Herbert Xu
2026-05-05 23:17 ` Andy Lutomirski
2026-05-06 0:17 ` Eric Biggers
2026-05-06 14:42 ` Jeff Barnes
2026-05-10 15:54 ` Kamran Khan
2026-05-10 16:32 ` Eric Biggers [this message]
2026-05-10 18:06 ` Andy Lutomirski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260510163204.GA2279@sol \
--to=ebiggers@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=jeffbarnes@linux.microsoft.com \
--cc=kz@inspirated.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=netdev@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox