FROMLIST:crypto: qce - Fix crypto self-test failures#1450
Conversation
Remove algorithms that are either unsafe or deprecated and have no in-kernel users that cannot be served by the ARM CE implementations. AES-ECB reveals plaintext patterns (identical plaintext blocks produce identical ciphertext blocks) and should not be exposed as a hardware- accelerated primitive. DES, Triple DES and HMAC-SHA1 have been deprecated for years. Remove sha1, ecb(aes), ecb(des), cbc(des), ecb(des3_ede), cbc(des3_ede), hmac(sha1) and all AEAD variants built on these primitives as well as authenc(hmac(sha256),cbc(des)). Also clean up the - now dead - code, flags and constants. Cc: stable@vger.kernel.org Acked-by: Eric Biggers <ebiggers@kernel.org> Tested-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/linux-arm-msm/20260622-qce-fix-self-tests-v4-1-4f82ffa716c6@oss.qualcomm.com/ Signed-off-by: Roopak Houji <rhouji@qti.qualcomm.com>
BAM DMA cannot process zero-length transfers. For plain hashes this is handled by returning the precomputed hash of the empty message (tmpl->hash_zero), but for keyed HMAC the result depends on the key and cannot be a constant. As a result, hmac(sha256) produced an incorrect digest for an empty message and the crypto self-tests failed. Allocate a software fallback ahash for the HMAC transforms and use it to compute the digest whenever the message is empty (in both the .final() and .digest() paths). The fallback is allocated in a dedicated cra_init for the HMAC algorithms and is excluded from matching the crypto engine's own algorithm to avoid recursion. It is kept keyed in sync with the hardware transform in .setkey(). Cc: stable@vger.kernel.org Fixes: ec8f5d8 ("crypto: qce - Qualcomm crypto engine driver") Tested-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/linux-arm-msm/20260622-qce-fix-self-tests-v4-2-4f82ffa716c6@oss.qualcomm.com/ Signed-off-by: Roopak Houji <rhouji@qti.qualcomm.com>
qcomlnxci
requested review from
a team and
sonineerajkumar
and removed request for
a team
🔨 Build Failure Analysis — PR #1450PR: #1450
Verdict1 of 94 merge conflicts is directly caused by this PR; 93 are pre-existing integration issues unrelated to PR #1450. 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #1450PR: #1450
Verdict1 of 5 merge conflicts is directly related to PR changes; 4 conflicts are pre-existing issues in the integration branch that affect the crypto/qce subsystem context. 📎 Detailed analysis: Full report |
PR #1450 — validate-patchPR: #1450
Final Summary
|
PR #1450 — checker-log-analyzerPR: #1450
Detailed report: Full report
|
XTS is not defined for an empty plaintext: it requires at least one full block of data. The driver treated a zero-length request as a successful no-op, so the crypto self-tests "unexpectedly succeeded" when -EINVAL was expected. Return -EINVAL for empty XTS requests while keeping the no-op behavior for the other ciphers, which the crypto engine simply cannot process due to its DMA not supporting zero-length transfers. Cc: stable@vger.kernel.org Fixes: f087894 ("crypto: qce - Return error for zero length messages") Tested-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/linux-arm-msm/20260622-qce-fix-self-tests-v4-3-4f82ffa716c6@oss.qualcomm.com/ Signed-off-by: Roopak Houji <rhouji@qti.qualcomm.com>
In CTR mode, the IV acts as the initial counter block. APer NIST SP 800-38A, after a CTR mode operation the next unused counter value is: IV_next = IV_in + ceil(cryptlen / AES_BLOCK_SIZE) The skcipher requires req->iv to hold this updated counter on completion, ensuring chained requests produce correct results. Referring to Crypto6.0 documentation, Section 2.2.5 says: "The count value increments automatically once per block of data (in AES, a block is 16 bytes) based on the value in the CRYPTO_ENCR_CNTR_MASK registers." QCE increments internal counter register once per full 16-byte block(for ctr-aes) is processed. In case of partial request length, the hardware uses the current counter to generate keystreams but does not increment the counter register afterwards. So the counter value written in CRYPTO_ENCR_CNTRn_IVn later once read by software is one less than the expected value. Crypto selftest framework capture this scenario with test vector 4 comprising of a 499-byte payload (31 full blocks + 3 partial bytes). Error: [ 5.606169] alg: skcipher: ctr-aes-qce encryption test failed (wrong output IV) on test vector 4, cfg="in-place (one sglist)" [ 5.606176] 00000000: e7 82 1d b8 53 11 ac 47 e2 7d 18 d6 71 0c a7 61 [ 5.606192] alg: self-tests for ctr(aes) using ctr-aes-qce failed (rc=-22) Expected iv_out: 0x62 (iv_in + 32) Obtained iv_out: 0x61 (iv_in + 31, partial block not counted) To fix this, just increase the counter value for partial block requests by 1 and for the full block size requests, don't take any action as expected value is already returned by the hardware. Cc: stable@vger.kernel.org Fixes: 3e806a1 ("crypto: qce - update the skcipher IV") Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com> Tested-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/linux-arm-msm/20260622-qce-fix-self-tests-v4-4-4f82ffa716c6@oss.qualcomm.com/ Signed-off-by: Roopak Houji <rhouji@qti.qualcomm.com>
…al block ctr(aes) is registered with a block size of 1, so the crypto API hands the driver requests whose length is not a multiple of the AES block size. The crypto engine, however, stalls waiting for a full block of input in that case, leaving the operation incomplete and failing the request (and the crypto self-tests) with a hardware operation error. Route AES-CTR requests with a partial final block to the software fallback, which already handles the other cases the engine cannot. Cc: stable@vger.kernel.org Fixes: bb5c863 ("crypto: qce - fix ctr-aes-qce block, chunk sizes") Tested-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/linux-arm-msm/20260622-qce-fix-self-tests-v4-5-4f82ffa716c6@oss.qualcomm.com/ Signed-off-by: Roopak Houji <rhouji@qti.qualcomm.com>
The QCE hardware does not support AES XTS mode when key1 and key2 are
equal. The driver was handling this by unconditionally rejecting the
keys with -ENOKEY(-126), regardless of whether FIPS mode is active or
the FORBID_WEAK_KEYS flag is set.
[ 5.599170] alg: skcipher: xts-aes-qce setkey failed on test vector 0; expected_error=0, actual_error=-126, flags=0x1
[ 5.599184] alg: self-tests for xts(aes) using xts-aes-qce failed (rc=-126)
In general for weak keys,
- If FIPS mode is active or FORBID_WEAK_KEYS is set: return -EINVAL.
- In non-FIPS mode, Accept the key and encrypt successfully.
Since QCE was returning -ENOKEY for non-FIPS mode whereas the
expectation is to encrypt content and return success, the selftest saw a
mismatch and failed.
There are two problems in QCE behavior:
* -ENOKEY is returned instead of -EINVAL for the FIPS/weak-key
rejection case.
* key1 == key2 is rejected even in non-FIPS mode
Fix xts-aes-qce behavior by using generic helper xts_verify_key() to
reject keys early with -EINVAL for FIPS mode active(or FORBID_WEAK_KEYS
set). For non-FIPS mode, since QCE hardware cannot accept the keys, use
software fallback mechanism to encrypt the data.
Cc: stable@vger.kernel.org
Fixes: f0d078d ("crypto: qce - Return unsupported if key1 and key 2 are same for AES XTS algorithm")
Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
Tested-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://lore.kernel.org/linux-arm-msm/20260622-qce-fix-self-tests-v4-6-4f82ffa716c6@oss.qualcomm.com/
Signed-off-by: Roopak Houji <rhouji@qti.qualcomm.com>
…lock CCM builds on AES-CTR for encryption, and the crypto engine stalls on a partial final block just as it does for plain ctr(aes): a payload whose length is not a multiple of the AES block size leaves the operation incomplete and fails with a hardware operation error. This was caught by the ccm(aes) crypto self-tests. Force the software fallback for CCM requests whose message length is not block aligned, reusing the driver's existing need_fallback mechanism. Cc: stable@vger.kernel.org Fixes: 9363efb ("crypto: qce - Add support for AEAD algorithms") Tested-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/linux-arm-msm/20260622-qce-fix-self-tests-v4-7-4f82ffa716c6@oss.qualcomm.com/ Signed-off-by: Roopak Houji <rhouji@qti.qualcomm.com>
The crypto engine reliably processes CCM only when the message payload is a single contiguous buffer. The associated data is already linearized into a bounce buffer before being submitted, but when the payload itself is split across multiple scatterlist entries the engine stalls waiting for input and the request fails with a hardware operation error. This was uncovered by the crypto self-tests, which feed the algorithms randomly fragmented buffers. Detect a payload that spans more than one scatterlist entry (in either the source or the destination, skipping past the associated data) and route the request to the software fallback. Cc: stable@vger.kernel.org Fixes: 9363efb ("crypto: qce - Add support for AEAD algorithms") Tested-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/linux-arm-msm/20260622-qce-fix-self-tests-v4-8-4f82ffa716c6@oss.qualcomm.com/ Signed-off-by: Roopak Houji <rhouji@qti.qualcomm.com>
roopak-houji
force-pushed
the
tech/security/crypto
branch
from
cd39c18 to
0952547
Compare
|
This is in response to the Build Failure Analysis posted by qlijarvis which flagged Issue To verify this claim, the 8 patches from this PR were manually applied via git am directly Below are the Logs rhouji@hu-rhouji-hyd:/local/mnt/workspace/linux-next/kernel$ git branch
rhouji@hu-rhouji-hyd:/local/mnt/workspace/linux-next/kernel$ git pull --all rhouji@hu-rhouji-hyd:/local/mnt/workspace/linux-next/kernel$ git am *.patch rhouji@hu-rhouji-hyd:/local/mnt/workspace/linux-next/kernel$ git log --oneline ✅ All 8 patches applied cleanly — zero conflicts, zero rejections. |
🔨 Build Failure Analysis — PR #1450PR: #1450
Verdict5 of 106 merge conflicts are directly related to this PR's changes in drivers/crypto/qce/; the remaining 101 conflicts are pre-existing integration issues unrelated to this PR. 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #1450PR: #1450
VerdictThis is NOT a compilation failure. The build failed during the merge/integration phase with 106 total merge conflicts. Only 1 conflict (drivers/crypto/qce/common.c) is directly related to PR changes; the remaining 105 conflicts are pre-existing integration issues in the base branch (tech/security/crypto) that are unrelated to this PR's changes. 📎 Detailed analysis: Full report |
PR #1450 — validate-patchPR: #1450
Final Summary
|
PR #1450 — checker-log-analyzerPR: #1450
Detailed report: Full report
|
3 participants
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:
derivation was incorrect
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
Tested-by: Kuldeep Singh kuldeep.singh@oss.qualcomm.com
Signed-off-by: Kuldeep Singh kuldeep.singh@oss.qualcomm.com
Link: https://lore.kernel.org/linux-arm-msm/20260622-qce-fix-self-tests-v4-0-4f82ffa716c6@oss.qualcomm.co…
Signed-off-by: Roopak Houji rhouji@qti.qualcomm.com