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

[Demi Marie Obenour <demiobenour@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3824 bytes --]

On 7/24/26 12:32, Dominique Martinet wrote:
> Eric Biggers wrote on Fri, Jul 24, 2026 at 09:00:34AM -0700:
>> On Sat, Jul 25, 2026 at 12:35:55AM +0900, Dominique Martinet wrote:
>>> The tool source is available here:
>>> https://github.com/nxp-imx/crypto_af_alg
>>> (which now fails with:
>>> bind(3, {sa_family=AF_ALG, salg_type="skcipher", salg_feat=0, salg_mask=0, salg_name="tk(cbc(aes))"}, 88) = -1 ENOENT (No such file or directory)
>>> )
>>>
>>>
>>> I don't particularily care for the API used as long as we can keep using
>>> the hardware key, but as far as I can see there's no alternative API --
>>> what's the path forward?
>>
>> There's no "tk(cbc(aes))" algorithm in the upstream kernel.  So, it's
>> not possible that this ever worked with upstream.  Given that, there's
>> no regression in upstream for this program, and it wouldn't be
>> appropriate to consider a sysctl knob in upstream at this time.
> 
> Bleh, you are correct, it's an NXP patch in
> drivers/crypto/caam/caamalg.c that they've been carrying in their
> tree(s) since 2018[1] and has apparently never been upstreamed...
> [1] https://github.com/nxp-imx/linux-imx/commit/6868c9e49c1854028fb46022daac3b1b10ca2c70
> 
> Sorry for not having checked, I was hoping for better.
> (I should be used to it by now...)
> 
> 
> Regardless of the specific algorithm, most recent SoCs flaunt some
> "secure element" or similiar hardware-backed keys (so one wouldn't be
> able to decrypt $whatever without running on the specific board it was
> intended for); I'm sure _some_ of them are upstream?
> (Never used it so not sure if they are reachable from af_alg, but for
> example drivers/crypto/ccree/cc_cipher.c talks about hardware key...)
> 
> 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...

I actually had this thought myself, though with a different
use-case: preventing long-term keys (like TLS and SSH keys and
cookie signing/encryption keys) from being accidentally leaked.

I came up with a much simpler API than AF_ALG:

1. Generate a file descriptor and a wrapping key.  The wrapping key
   is used to encrypt data that will be imported.

2. Import an encrypted secret key.  The key contains both the secret
   key and the algorithm it will be used with.

3. Optionally, attach a restriction policy that requires data to
   be signed to start with a certain prefix.  This provides domain
   separation in contexts where the same key is used for multiple
   purposes.

4. Pass the file descriptor to another process via SCM_RIGHTS.

5. The receiving process can use ioctls to perform secret-key
   operations, such as ML-KEM, ML-DSA, XChaCha20-Poly1305, and
   XAES-256-GCM.

6. When the file descriptor is closed, the secret key is securely
   deleted.
   
Compared to AF_ALG, the kernel attack surface is very small.  It's not
quite a "hello world" character device driver, but compared to many
of the other drivers in the kernel, it is tiny.  Furthermore, the
whole thing should be able to be written in safe Rust.

To keep the attack surface minimal, this would only use library
functions, so there would be no support for hardware-wrapped keys.

I don't plan to work on this myself, but I think it's of potential
value in the future.  For asymmetric algorithms, the overhead of a
system call should be fairly small compared to the operation itself.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]