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

[Dominique Martinet <asmadeus@codewreck.org>]

Eric Biggers wrote on Sat, Jul 25, 2026 at 10:49:03AM -0700:
> > "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.

PKCS#11 is something I (wrongly) picked up from Qualcomm doc here:
https://docs.qualcomm.com/doc/80-70018-11/topic/key-management.html#key-management

But honestly I hadn't read up all that much, and I had been confused as
the previous page talked about their inline crypto engine but this seems
to be more general.
It's been a busy weekend/week/month/year...

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

Thanks for this pointer as well; this is much more clear to me, and also
seems to cover keys generated directly on hardware that are not
accessible so it pretty much covers what we're doing manually as well
(once I finally realized that this sits on the SoC side, not the
UFS/eMMC side, as key generation didn't make sense there)

> > 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@kernel.org/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)
> 
> 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.

From my 9p maintainer hat I see plenty of patches without 'Cc stable'
get backported every merge window, but this is a potential breakage so
I guess it might not have made it (my patches merged in v7.2-rc1 (same
time as this) were backported last week)

I generally agree with your assessement of vulnerabilities everywhere so
would have expected it to make the cut, time will tell.

> 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.

Right, I can definitely relate to this, and it's hard to know who
actually uses what especially when vendors add their own sauce on top of
it and don't seem to bother about updating much...

> 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!

FWIW I'm not affiliated with NXP or any SoC vendor (we're making
embedded boards and providing an OS for it); I'm just bouncing around
between a rock and a hard place trying to ensure my users can keep
updating their kernel without losing access to their data :)

The discussion has been enlightening anyway, and thanks to Richard I've
seen a way forward if we get a backport (or even possibly even move
forward with it ahead of stable), it's appreciated.

Thanks again,
-- 
Dominique Martinet