linux/drivers/crypto/qce, branch v5.8

crypto: qce - fix wrong config symbol reference

2020-03-12T12:00:13Z

The CONFIG_CRYPTO_DEV_QCE_SOFT_THRESHOLD symbol was renamed during development, but the stringify reference in the parameter description sneaked by unnoticed. Signed-off-by: Eneas U de Queiroz Signed-off-by: Herbert Xu

crypto: qce - handle AES-XTS cases that qce fails

2020-02-13T09:05:27Z

QCE hangs when presented with an AES-XTS request whose length is larger than QCE_SECTOR_SIZE (512-bytes), and is not a multiple of it. Let the fallback cipher handle them. Signed-off-by: Eneas U de Queiroz Signed-off-by: Herbert Xu

crypto: qce - use AES fallback for small requests

2020-02-13T09:05:27Z

Process small blocks using the fallback cipher, as a workaround for an observed failure (DMA-related, apparently) when computing the GCM ghash key. This brings a speed gain as well, since it avoids the latency of using the hardware engine to process small blocks. Using software for all 16-byte requests would be enough to make GCM work, but to increase performance, a larger threshold would be better. Measuring the performance of supported ciphers with openssl speed, software matches hardware at around 768-1024 bytes. Considering the 256-bit ciphers, software is 2-3 times faster than qce at 256-bytes, 30% faster at 512, and about even at 768-bytes. With 128-bit keys, the break-even point would be around 1024-bytes. This adds the 'aes_sw_max_len' parameter, to set the largest request length processed by the software fallback. Its default is being set to 512 bytes, a little lower than the break-even point, to balance the cost in CPU usage. Signed-off-by: Eneas U de Queiroz Signed-off-by: Herbert Xu

crypto: qce - use cryptlen when adding extra sgl

2020-02-13T09:05:26Z

The qce crypto driver appends an extra entry to the dst sgl, to maintain private state information. When the gcm driver sends requests to the ctr skcipher, it passes the authentication tag after the actual crypto payload, but it must not be touched. Commit 1336c2221bee ("crypto: qce - save a sg table slot for result buf") limited the destination sgl to avoid overwriting the authentication tag but it assumed the tag would be in a separate sgl entry. This is not always the case, so it is better to limit the length of the destination buffer to req->cryptlen before appending the result buf. Signed-off-by: Eneas U de Queiroz Signed-off-by: Herbert Xu

crypto: remove CRYPTO_TFM_RES_BAD_KEY_LEN

2020-01-09T03:30:53Z

The CRYPTO_TFM_RES_BAD_KEY_LEN flag was apparently meant as a way to make the ->setkey() functions provide more information about errors. However, no one actually checks for this flag, which makes it pointless. Also, many algorithms fail to set this flag when given a bad length key. Reviewing just the generic implementations, this is the case for aes-fixed-time, cbcmac, echainiv, nhpoly1305, pcrypt, rfc3686, rfc4309, rfc7539, rfc7539esp, salsa20, seqiv, and xcbc. But there are probably many more in arch/*/crypto/ and drivers/crypto/. Some algorithms can even set this flag when the key is the correct length. For example, authenc and authencesn set it when the key payload is malformed in any way (not just a bad length), the atmel-sha and ccree drivers can set it if a memory allocation fails, and the chelsio driver sets it for bad auth tag lengths, not just bad key lengths. So even if someone actually wanted to start checking this flag (which seems unlikely, since it's been unused for a long time), there would be a lot of work needed to get it working correctly. But it would probably be much better to go back to the drawing board and just define different return values, like -EINVAL if the key is invalid for the algorithm vs. -EKEYREJECTED if the key was rejected by a policy like "no weak keys". That would be much simpler, less error-prone, and easier to test. So just remove this flag. Signed-off-by: Eric Biggers Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: qce - allow building only hashes/ciphers

2019-12-27T10:18:04Z

Allow the user to choose whether to build support for all algorithms (default), hashes-only, or skciphers-only. The QCE engine does not appear to scale as well as the CPU to handle multiple crypto requests. While the ipq40xx chips have 4-core CPUs, the QCE handles only 2 requests in parallel. Ipsec throughput seems to improve when disabling either family of algorithms, sharing the load with the CPU. Enabling skciphers-only appears to work best. Signed-off-by: Eneas U de Queiroz Signed-off-by: Herbert Xu

crypto: qce - initialize fallback only for AES

2019-12-27T10:18:04Z

Adjust cra_flags to add CRYPTO_NEED_FALLBACK only for AES ciphers, where AES-192 is not handled by the qce hardware, and don't allocate & free the fallback skcipher for other algorithms. Signed-off-by: Eneas U de Queiroz Signed-off-by: Herbert Xu

crypto: qce - update the skcipher IV

2019-12-27T10:18:04Z

Update the IV after the completion of each cipher operation. Signed-off-by: Eneas U de Queiroz Signed-off-by: Herbert Xu

crypto: qce - save a sg table slot for result buf

2019-12-27T10:18:04Z

When ctr-aes-qce is used for gcm-mode, an extra sg entry for the authentication tag is present, causing trouble when the qce driver prepares the dst-results sg table for dma. It computes the number of entries needed with sg_nents_for_len, leaving out the tag entry. Then it creates a sg table with that number plus one, used to store a result buffer. When copying the sg table, there's no limit to the number of entries copied, so the extra slot is filled with the authentication tag sg. When the driver tries to add the result sg, the list is full, and it returns EINVAL. By limiting the number of sg entries copied to the dest table, the slot for the result buffer is guaranteed to be unused. Signed-off-by: Eneas U de Queiroz Signed-off-by: Herbert Xu

crypto: qce - fix xts-aes-qce key sizes

2019-12-27T10:18:04Z

XTS-mode uses two keys, so the keysizes should be doubled in skcipher_def, and halved when checking if it is AES-128/192/256. Signed-off-by: Eneas U de Queiroz Signed-off-by: Herbert Xu