This extends the initial submission from Kuldeep.

The QCE hardware crypto engine has several limitations that cause it to
produce incorrect results or stall on certain inputs. This series fixes
several bugs and adds workaround allowing the deiver to pass crypto
self-tests.

The failures addressed are:

- HMAC self-test failures for empty messages
- AES-XTS returning success on zero-length input (should be -EINVAL)
- AES-CTR: partial final block causes the engine to stall, output IV
  derivation was incorrect
- AES-XTS with key1 == key2 is not supported by the CE
- AES-CCM: partial final block and fragmented payload both stall the
  engine

All fixes were tested on an SM8650 QRD board with
CONFIG_CRYPTO_SELFTESTS=y and CONFIG_CRYPTO_SELFTESTS_FULL=y.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
Changes in v6:
- Handle all zero-length HMAC finalizations (like imported state with
  data already hashed), not only the genuinely empty message case
- Add an additional patch addressing the fragmented skcipher payload
  issue
- Link to v5: https://patch.msgid.link/20260706-qce-fix-self-tests-v5-0-86f461ff1829@oss.qualcomm.com

Changes in v5:
- Dropped patch 1/8 that's already queued
- Use the pre-allocated fallback ahash for HMAC transforms (Herbert)
- Link to v4: https://patch.msgid.link/20260622-qce-fix-self-tests-v4-0-4f82ffa716c6@oss.qualcomm.com

Changes in v4:
- Remove remaining ECB and DES3 bits
- Pick up tags
- Link to v3: https://patch.msgid.link/20260617-qce-fix-self-tests-v3-0-ecc2b4dedcfd@oss.qualcomm.com

Changes in v3:
- Remove even more algorithms and dead code in patch 1/8
- Link to v2: https://patch.msgid.link/20260615-qce-fix-self-tests-v2-0-dc911f1aad42@oss.qualcomm.com

Changes in v2:
- Add fixes for the full suite of crypto self-tests
- Add Fixes and Cc tags
- Link to v1: https://patch.msgid.link/20260610-qce_selftest_fix-v1-0-1b0504783a46@oss.qualcomm.com/

---
Bartosz Golaszewski (6):
      crypto: qce - Fix HMAC self-test failures for empty messages
      crypto: qce - Reject empty messages for AES-XTS
      crypto: qce - Use a fallback for AES-CTR with a partial final block
      crypto: qce - Use fallback for fragmented skcipher payloads
      crypto: qce - Use a fallback for CCM with a partial final block
      crypto: qce - Use fallback for CCM with a fragmented payload

Kuldeep Singh (2):
      crypto: qce - Fix CTR-AES for partial block requests
      crypto: qce - Fix xts-aes-qce for weak keys

 drivers/crypto/qce/aead.c     | 32 +++++++++++++++++++++++-
 drivers/crypto/qce/cipher.h   |  1 +
 drivers/crypto/qce/common.h   |  1 -
 drivers/crypto/qce/sha.c      | 58 ++++++++++++++++++++++++++++++++-----------
 drivers/crypto/qce/skcipher.c | 50 ++++++++++++++++++++++++++++++-------
 5 files changed, 116 insertions(+), 26 deletions(-)
---
base-commit: f6fa674bd75f9ed0e74f4ca85f88a6e461b5f230
change-id: 20260610-qce-fix-self-tests-492ffd2ef955

Best regards,
-- 
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

On Fri, Jul 17, 2026 at 05:53:29PM +0200, Bartosz Golaszewski wrote:
> This extends the initial submission from Kuldeep.
> 
> The QCE hardware crypto engine has several limitations that cause it to
> produce incorrect results or stall on certain inputs. This series fixes
> several bugs and adds workaround allowing the deiver to pass crypto
> self-tests.
> 
> The failures addressed are:

I was also looking at how the request queueing works in this driver.
qce_handle_queue() gets invoked synchronously from almost all the
ahash/skcipher/aead API entry points.

However, it takes a mutex, which can sleep.

Not a great choice when these APIs can be called in softirq context.

I strongly suspect this would crash if anyone actually tried to use this
with IPsec, for example.

This is interesting when we consider that the driver implements the
"rfc4309(ccm(aes))" algorithm, whose exclusive purpose is IPsec.

I'm not sure if there are some out of tree patches going on, or if this
was just never actually tested with what it was theoretically supposed
to have been useful for.  But I'd guess the latter.

- Eric

On Thu, Jul 23, 2026 at 01:27:04PM -0700, Eric Biggers wrote:
> On Fri, Jul 17, 2026 at 05:53:29PM +0200, Bartosz Golaszewski wrote:
> > This extends the initial submission from Kuldeep.
> > 
> > The QCE hardware crypto engine has several limitations that cause it to
> > produce incorrect results or stall on certain inputs. This series fixes
> > several bugs and adds workaround allowing the deiver to pass crypto
> > self-tests.
> > 
> > The failures addressed are:

I also noticed that qce_aead_done() compares MACs using memcmp() instead
of crypto_memneq().  That makes it vulnerable to timing side-channel
attacks (https://en.wikipedia.org/wiki/Timing_attack).

This is yet another thing that is inconsistent with claims that this
driver improves security.

Of course, the software implementation does not have this problem.

- Eric