Re: [PATCH] crypto: qce - Replace with stub driver
Eric Biggers <[email protected]>
| Newsgroups | org.kernel.vger.linux-crypto,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
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