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

[Eric Biggers <ebiggers@kernel.org>]

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.

Does the perceived value perhaps come merely from "offering" FIPS
certified cryptography on the system -- then not actually using it in
practice?  That can maybe be understandable in some cases, but it's also
not really something that belongs upstream where actual technical merit
is expected.  Also, could ICE be enough to check that checkbox?

- Eric