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

Demi Marie Obenour <[email protected]> Sat, 25 Jul 2026 13:38:02 -0400

Newsgroups	org.kernel.vger.io-uring,org.kernel.vger.linux-crypto,org.kernel.vger.linux-doc,org.kernel.vger.linux-kernel,org.kernel.vger.linux-perf-users,org.kernel.vger.linux-s390,org.kernel.vger.netdev
Message-ID	<[email protected]>

On 7/25/26 03:37, 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.

The Qualcomm Inline Crypto Engine is a type of inline encryption
hardware.  Inline encryption hardware is integrated in the I/O path,
so using it doesn't involve any extra copies or interrupts.  The data
goes from memory to crypto hardware to the I/O target, and from the
I/O target to crypto hardware to memory.  The ciphertext is never
written to memory.

In the case of the Qualcomm Inline Crypto Engine, the I/O target is
the the storage device.  On Android, that's eMMC or UFS.  I would be
very surprised if the Inline Crypto Engine was any slower than the
storage device connected to it.

In Linux, inline storage encryption is exposed via the blk-crypto
framework.  It works very well and is widely used on Android.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

OpenPGP_signature.asc (application/pgp-signature, 833 B)