aboutsummaryrefslogtreecommitdiffstats
path: root/target/linux/ipq40xx/patches-5.4/048-crypto-qce-use-AES-fallback-for-small-requests.patch
diff options
context:
space:
mode:
authorEneas U de Queiroz <cotequeiroz@gmail.com>2019-12-20 10:52:17 -0300
committerChristian Lamparter <chunkeey@gmail.com>2020-02-28 22:46:09 +0100
commit13b8404b1eaaa51027cae42c8152b9123d92a425 (patch)
treea3193bb01ead9a0d3ea281b619161da6e86ea1ce /target/linux/ipq40xx/patches-5.4/048-crypto-qce-use-AES-fallback-for-small-requests.patch
parentee4a0afdcdf0c11528d685efd64fb8f4b4efcbb1 (diff)
downloadupstream-13b8404b1eaaa51027cae42c8152b9123d92a425.tar.gz
upstream-13b8404b1eaaa51027cae42c8152b9123d92a425.tar.bz2
upstream-13b8404b1eaaa51027cae42c8152b9123d92a425.zip
ipq40xx: qce - add fixes for AES ciphers
This backports commits from master that fix AES ciphers when using the qce driver: - A couple of simple fixes for CTR and XTS modes used with AES: * 041-crypto-qce-fix-ctr-aes-qce-block-chunk-sizes.patch * 042-crypto-qce-fix-xts-aes-qce-key-sizes.patch - A fix for a bug that affected cases when there were more entries in the input sg list than necessary to actually encrypt, resulting in failure in gcm, where the authentication tag is present after the encryption data: * 043-crypto-qce-save-a-sg-table-slot-for-result-buf.patch - A fix to update the IV buffer passed to the driver from the kernel: * 044-crypto-qce-update-the-skcipher-IV.patch - A patch that reduces memory footprint and driver initialization by only initializing the fallback mechanism where it is actually used: * 046-crypto-qce-initialize-fallback-only-for-AES.patch - Three patches that make gcm and xts modes work with the qce driver, and improve performance with small blocks: * 047-crypto-qce-use-cryptlen-when-adding-extra-sgl.patch * 048-crypto-qce-use-AES-fallback-for-small-requests.patch * 049-crypto-qce-handle-AES-XTS-cases-that-qce-fails.patch - A patch that allows the hashes/ciphers to be built individually. * 051-crypto-qce-allow-building-only-hashes-ciphers.patch Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com> [renumbered patches, added patches from dropped commit, refreshed, 5.4] Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Diffstat (limited to 'target/linux/ipq40xx/patches-5.4/048-crypto-qce-use-AES-fallback-for-small-requests.patch')
-rw-r--r--target/linux/ipq40xx/patches-5.4/048-crypto-qce-use-AES-fallback-for-small-requests.patch113
1 files changed, 113 insertions, 0 deletions
diff --git a/target/linux/ipq40xx/patches-5.4/048-crypto-qce-use-AES-fallback-for-small-requests.patch b/target/linux/ipq40xx/patches-5.4/048-crypto-qce-use-AES-fallback-for-small-requests.patch
new file mode 100644
index 0000000000..d9a6c4dff9
--- /dev/null
+++ b/target/linux/ipq40xx/patches-5.4/048-crypto-qce-use-AES-fallback-for-small-requests.patch
@@ -0,0 +1,113 @@
+From ce163ba0bf298f1707321ac025ef639f88e62801 Mon Sep 17 00:00:00 2001
+From: Eneas U de Queiroz <cotequeiroz@gmail.com>
+Date: Fri, 7 Feb 2020 12:02:26 -0300
+Subject: [PATCH 10/11] crypto: qce - use AES fallback for small requests
+
+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 <cotequeiroz@gmail.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+---
+
+--- a/drivers/crypto/Kconfig
++++ b/drivers/crypto/Kconfig
+@@ -628,6 +628,29 @@ config CRYPTO_DEV_QCE
+ hardware. To compile this driver as a module, choose M here. The
+ module will be called qcrypto.
+
++config CRYPTO_DEV_QCE_SW_MAX_LEN
++ int "Default maximum request size to use software for AES"
++ depends on CRYPTO_DEV_QCE && CRYPTO_DEV_QCE_SKCIPHER
++ default 512
++ help
++ This sets the default maximum request size to perform AES requests
++ using software instead of the crypto engine. It can be changed by
++ setting the aes_sw_max_len parameter.
++
++ Small blocks are processed faster in software than hardware.
++ 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.
++
++ The default is set a little lower, to 512 bytes, to balance the
++ cost in CPU usage. The minimum recommended setting is 16-bytes
++ (1 AES block), since AES-GCM will fail if you set it lower.
++ Setting this to zero will send all requests to the hardware.
++
++ Note that 192-bit keys are not supported by the hardware and are
++ always processed by the software fallback, and all DES requests
++ are done by the hardware.
++
+ config CRYPTO_DEV_QCOM_RNG
+ tristate "Qualcomm Random Number Generator Driver"
+ depends on ARCH_QCOM || COMPILE_TEST
+--- a/drivers/crypto/qce/skcipher.c
++++ b/drivers/crypto/qce/skcipher.c
+@@ -5,6 +5,7 @@
+
+ #include <linux/device.h>
+ #include <linux/interrupt.h>
++#include <linux/moduleparam.h>
+ #include <linux/types.h>
+ #include <crypto/aes.h>
+ #include <crypto/internal/des.h>
+@@ -12,6 +13,13 @@
+
+ #include "cipher.h"
+
++static unsigned int aes_sw_max_len = CONFIG_CRYPTO_DEV_QCE_SW_MAX_LEN;
++module_param(aes_sw_max_len, uint, 0644);
++MODULE_PARM_DESC(aes_sw_max_len,
++ "Only use hardware for AES requests larger than this "
++ "[0=always use hardware; anything <16 breaks AES-GCM; default="
++ __stringify(CONFIG_CRYPTO_DEV_QCE_SOFT_THRESHOLD)"]");
++
+ static LIST_HEAD(skcipher_algs);
+
+ static void qce_skcipher_done(void *data)
+@@ -166,15 +174,10 @@ static int qce_skcipher_setkey(struct cr
+ switch (IS_XTS(flags) ? keylen >> 1 : keylen) {
+ case AES_KEYSIZE_128:
+ case AES_KEYSIZE_256:
++ memcpy(ctx->enc_key, key, keylen);
+ break;
+- default:
+- goto fallback;
+ }
+
+- ctx->enc_keylen = keylen;
+- memcpy(ctx->enc_key, key, keylen);
+- return 0;
+-fallback:
+ ret = crypto_sync_skcipher_setkey(ctx->fallback, key, keylen);
+ if (!ret)
+ ctx->enc_keylen = keylen;
+@@ -224,8 +227,9 @@ static int qce_skcipher_crypt(struct skc
+ rctx->flags |= encrypt ? QCE_ENCRYPT : QCE_DECRYPT;
+ keylen = IS_XTS(rctx->flags) ? ctx->enc_keylen >> 1 : ctx->enc_keylen;
+
+- if (IS_AES(rctx->flags) && keylen != AES_KEYSIZE_128 &&
+- keylen != AES_KEYSIZE_256) {
++ if (IS_AES(rctx->flags) &&
++ ((keylen != AES_KEYSIZE_128 && keylen != AES_KEYSIZE_256) ||
++ req->cryptlen <= aes_sw_max_len)) {
+ SYNC_SKCIPHER_REQUEST_ON_STACK(subreq, ctx->fallback);
+
+ skcipher_request_set_sync_tfm(subreq, ctx->fallback);