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

[Demi Marie Obenour]

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.

Is there anything on that list that you don't plan to convert
to the crypto library?
> 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?

I agree with all of these points.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature