Re: [PATCH] crypto: qce - Replace with stub driver

[Eric Biggers <ebiggers@kernel.org>]

On Thu, Aug 13, 2026 at 05:00:28PM -0400, Demi Marie Obenour wrote:
> On 8/13/26 16:10, Eric Biggers wrote:
> > On Thu, Aug 13, 2026 at 03:09:36PM -0400, Demi Marie Obenour wrote:
> >>> SM8650 with the QCE is FIPS 140-2 certified and apparently this makes
> >>> a difference. Don't ask me if that makes sense, I don't claim to understand
> >>> the legal aspects of it.
> >>
> >> That sounds like the kind of thing that would cause someone to use
> >> a worse implementation of cryptographic algorithms 🙂.
> >>
> >> For what it is worth, many common uses of kernel cryptography can't
> >> use the QCE.  This notably applies to the CSPRNG (/dev/urandom etc),
> >> storage encryption, and AF_ALG.  Therefore, I expect that anyone who
> >> needs FIPS 140 compliance with Linux needs to ensure that the software
> >> crypto is certified, as that's what actually gets used in most cases.
> > 
> > Well there's that, and also the Inline Crypto Engine (which is actually
> > being used and is unrelated to QCE) has its own FIPS certification.
> > 
> > Which upstream kernel feature, if any, is QCE being used with?  I have
> > asked this multiple times and still not gotten an answer.
> Historically AF_ALG has been used to access FIPS-certified crypto
> from userspace, but that no longer can be used with QCE.  Most kernel
> features reject CRYPTO_ALG_ASYNC, CRYPTO_ALG_ALLOCATES_MEMORY, or both.
> If I exclude tests and fallback paths of other drivers, that leaves
> crypto/asymmetric_keys/public_key.c (hashing), BPF, MACsec, OpenVPN
> data channel offload, ecryptfs, Ceph, SMB, IPsec, mac802154, TIPC, TLS,
> and crypto/kpp.c.  AF_ALG only allows offload drivers for cbc(paes),
> which QCE doesn't implement.  QCE is broken with IPsec and probably
> some other networking protocols, as it would wind up taking a mutex
> in softirq context.

It's a far more narrow list than even that.  asymmetric_keys uses the
shash API, so it cannot use QCE.  BPF crypto uses the lskcipher API, so
it cannot use QCE.  MACsec uses AES-GCM which QCE driver doesn't have.
OpenVPN uses AES-GCM or ChaCha20Poly1305, neither of which the QCE
driver has.  The non-legacy Ceph protocol uses AES-GCM, which again the
QCE driver doesn't have.  IPsec does decryption in softirq context,
which the QCE driver doesn't support.  QCE driver does not implement kpp
algorithms.  SMB, TIPC, TLS, all usually use AES-GCM as well.  Until
just a couple months ago ksmbd crashed if passed an async algorithm,
which proves it was never used with QCE.  There is really not much left,
maybe ecryptfs AES-CBC file contents encryption?  But even for that the
cra_priority makes it not actually used.

But we are going into the weeds here with trying to theorize some way
the code could theoretically be reached.  It seems it's really just not.
Or at least if there is a use it is not upstream and/or is not actually
the appropriate code to be using.

- Eric