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

[Eric Biggers]

On Sun, Jul 26, 2026 at 09:28:14AM +0200, Richard Weinberger wrote:
> On Sun, Jul 26, 2026 at 12:04 AM Eric Biggers <ebiggers@xxxxxxxxxx> wrote:
> > > You can create a CAAM BLOB (a generated and sealed key) using the
> > > trusted keys subsystem and use this BLOB
> > > later in AF_ALG to perform AES with a key invisible to userspace.
> > >
> > > e.g.
> > > kid=$(keyctl add trusted mykey "new 32 pk" @s)
> > > keyctl print $kid | xxd -r -p > blob.bin
> > > Then just create a caam_pkey_info in userspace and feed it into AF_ALG
> > > and perform AES with it.
> >
> > Well, specifically AES-CBC.  That's the only one that is in the driver.
> 
> Yes.
> 
> > > So, pretty please,  if you kill AF_ALG and all this, offer some way to
> > > achieve the same in userspace.
> >
> > If needed, "cbc(paes)" and/or "cbc-paes-caam" (whichever name it is
> > being accessed as) can be allowed as a special case, as a stop-gap.
> 
> Would be great.
> 
> > This would need confirmed use of that specific algorithm with upstream,
> > which we don't quite have yet.  Dominique had a confirmed use of
> > "tk(cbc(aes))", but that has never existed upstream in the first place,
> > so it's not something that could be allowlisted upstream.
> 
> It's "cbc(paes)".
> 
> From one of my demo applications:
> 
> struct sockaddr_alg sa = {
>        .salg_family = AF_ALG,
>        .salg_type = "skcipher",
>        .salg_name = "cbc(paes)",
> };
> 
> > You've only mentioned that it "can" be used in this way in upstream.
> > Can you confirm that it *is* used, and with an actual upstream algorithm
> > name, and if so which one(s)?  And if so, would you also be able to
> > share whether this is for dm-crypt or not?  We should remember that
> > dm-crypt accepts keys directly and AF_ALG is not needed to use it.
> 
> Well, if you require me to point to some open source application, sorry I can't.
> 
> But no, the use cases I know about are not dm-crypt.
> It's more allowing to encrypt/decrypt data in userspace without being able to
> extract the key from the device. Since the key is hardware bound too,
> it is device
> specific and you cannot decrypt on device B what you have encrypted on A, even
> if you share the BLOB.
> So, it's more like a building block for a poor man's secure element.
> 
> At $dayjob we've been recommending AF_ALG because it's a standard interface.
> Not like other ad-hoc horrors via sysfs or worse we've seen on some BSPs.

Then I would suggest that skcipher_bind() should check if the name is
"cbc(paes)", and if so use 0 instead of AF_ALG_CRYPTOAPI_MASK.  Please
go ahead and send a patch against mainline (for v7.2-rc6) if you're
interested.

On cryptodev/master (future 7.3) it should get an entry in the new
skcipher_allowlist as well: { "cbc(paes)", true }.  That would be a
separate patch.

With those it will keep working as root.  (And you mentioned in your
other email it's used only as root anyway.)

- Eric