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

[Demi Marie Obenour <demiobenour@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3850 bytes --]

On 8/13/26 17:34, Eric Biggers wrote:
> 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.
At this point I think it is quite clear that the following algorithms
provided by QCE are unusable no matter what userspace does:

- SHA256
- HMAC-SHA256
- AES-XTS
- authenc(hmac(sha256),cbc(aes))

Those should all be deleted as unreachable or unused code.  There are
also a lot of algorithms in other drivers that can also be removed.

If the driver was actually used, I _suspect_ it was by requesting it
explicitly via AF_ALG.  AF_ALG won't let you do that anymore, though.
The other possibilities I can think of are messing with priorities via
NETLINK_CRYPTO or somehow not building any software implementations
with a higher cra_priority than QCE.

Splitting the driver up would be much better than the current status
quo, though.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]