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

[Eric Biggers]

On Sat, Jul 25, 2026 at 04:37:24PM +0900, Dominique Martinet wrote:
> Thank you both for your time replying
> 
> Eric Biggers wrote on Fri, Jul 24, 2026 at 06:09:51PM +0000:
> > On Sat, Jul 25, 2026 at 01:32:12AM +0900, Dominique Martinet wrote:
> > > There's not much I can do about the vendor's kernel I'm stuck with, but
> > > that doesn't make having encryption material not accessible to userspace
> > > useless as a concept;
> > > forgetting about the sysctl for now, what are the alternatives API this
> > > kind of implementations could be based on?
> > > 
> > > I guess I should start looking at how tpm backed encryption works,
> > > some other day, it's getting late here...
> > 
> > First, we should remember that implementing hardware-bound keys via a
> > standalone crypto engine is a dated approach.  Inline crypto engines and
> > CPUs, which work much better than and are much easier to use than legacy
> > standalone crypto engines, can support hardware-bound keys as well.  The
> > former is already supported, and is already being widely used, in the
> > kernel via the hardware-wrapped inline crypto keys feature.  For the
> > latter, see e.g. RISC-V High Assurance Cryptography.  In the CPU case no
> > UAPI is even needed; userspace can just use it directly.
> 
> Thank you, this is exactly what I was asking about - my background isn't
> crypto and ultimately whatever direction is implemented will depend on
> $vendor and I'll just be following along, but I'll read up on this.
> 
> "Inline crypto engine" seems to be a qualcomm marketing term, but from
> looking at their doc the API seems to be PKCS#11 smart card?
> Having worked on these for some other hardware I can't say I find it
> easier to use than af alg, but it's definitely something that can be
> worked out.

I guess I should have written "inline encryption hardware", which is the
vendor-independent term we've been using in the kernel, just in case
anyone thinks "inline crypto engine" means the "Qualcomm Inline Crypto
Engine" specifically (but really, IMO they are just descriptive phrases
that mean the same thing).  There are many different hardware vendors
that have inline encryption hardware for UFS and/or eMMC.

Their interface is quite simple and doesn't use PKCS#11 at all.  I don't
know where you're seeing anything about PKCS#11.

See also the documentation in Documentation/block/inline-encryption.rst

> "The CPU case" (looking at the RISC-V High Assurance Cryptography) would
> be some CPU instructions (ISA) reserved for crypto ops?
> That's interesting, I had never seen this but I can see this would
> likely provide the best performance.. And if the ISA gain enough
> traction having them supported out of the box by OpenSSL or whatsnot
> might actually be possible, that'd be a great step forward.

Yes, and similar developments are also occurring on other CPU
architectures, like Intel's Key Locker.

> Right, sorry for asking about an out-of-tree driver, I hadn't realized
> since caam itself has been upstream for a while.
> 
> I was just curious about the double-take approach taken with these two patches:
>  crypto: af_alg - Drop support for off-CPU cryptography (this)
>  crypto: af_alg - Add af_alg_restrict sysctl, defaulting to 1 ([4])
> [4] https://lore.kernel.org/linux-crypto/20260622234803.6982-1-ebiggers@xxxxxxxxxx/T/#u
> 
> I assume part of it was just that the whitelist wasn't ready yet when
> this patch was merged, but as far as I understand if the whitelist
> sysctl is implemented this is basically noop?
> (Well, I guess it'll allow code simplification over time, but these
> hopefully won't be backported to stable kernels too aggressively.. While
> I fully expect to see this "Drop support for off-CPU crypto" patch to
> show up in a couple of weeks in older stable trees; and for practical
> purposes I don't see much way around just reverting it for now)
> 
> Thanks for putting up with me.

Neither of these patches is tagged with 'Cc stable', and I don't expect
them to be backported to stable kernels soon.  That being said, it seems
the people using LLMs to find vulnerabilities haven't focused much on
drivers/crypto/ yet.  Once they do, well, they will of course find
vulnerabilities everywhere (accessible from unprivileged userspace via
AF_ALG), and when that happens there may be little choice.

The addition of the af_alg_restrict sysctl (and the possibility of
userspace explicitly choosing to disable restrictions by setting
af_alg_restrict=0) doesn't necessarily mean that problematic
functionality should be, or should have been, moved under
af_alg_restrict=0 rather than removed outright.  It's just an option
that can be used if needed for compatibility reasons, if actual user
reports come in.  If something is not needed at all it can just be
dropped right away.  This actually happens way more often than people
might think, due to the immense amount of unnecessary functionality that
AF_ALG has: *many* crypto algorithms have been removed from AF_ALG over
the years without any complaints, since they were never used.

I'll also note that hardware crypto "decelerator" driver authors are
actually now *depending* on the drivers no longer being usable from
AF_ALG in mainline in order to argue for more relaxed driver inclusion
criteria.  I don't think they can have it both ways!

- Eric