I've been trying to make the Qualcomm Crypto Engine work with GCM-mode AES. I fixed some bugs, and added an option to build only hashes or skciphers, as the VPN performance increases if you leave some of that to the CPU. A discussion about this can be found here: https://github.com/openwrt/openwrt/pull/2518 I'm using openwrt to test this, and there's no support for kernel 5.x yet. So I have backported the recent skcipher updates, and tested this with 4.19. I don't have the hardware with me, but I have run-tested everything, working remotely. All of the skciphers directly implemented by the driver work. They pass the tcrypt tests, and also some tests from userspace using AF_ALG: https://github.com/cotequeiroz/afalg_tests However, I can't get gcm(aes) to work. When setting the gcm-mode key, it sets the ctr(aes) key, then encrypt a block of zeroes, and uses that as the ghash key. The driver fails to perform that encryption. I've dumped the input and output data, and they apparently are not touched by the QCE. The IV, which written to a buffer appended to the results sg list gets updated, but the results themselves are not. I'm not sure what goes wrong, if it is a DMA/cache problem, memory alignment, or whatever. If I take 'be128 hash' out of the 'data' struct, and kzalloc them separately in crypto_gcm_setkey (crypto/gcm.c), it encrypts the data just fine--perhaps the payload and the request struct can't be in the same page? However, it still fails during decryption of the very first tcrypt test vector (I'm testing with the AF_ALG program, using the same vectors as the kernel), in the final encryption to compute the authentication tag, in the same fashion as it did in 'crypto_gcm_setkey'. What this case has in common with the ghash key above is the input data, a single block of zeroes, so this may be a hardware bug. However, if I perform the same encryption using the AF_ALG test, it completes OK. I am not experienced enough with the Linux Kernel, or with the ARM architecture to wrap this up on my own, so I need some pointers to what to try next. To come up a working setup, I am passing any AES requests whose length is less than or equal to one AES block to the fallback skcipher. This hack is not a part of this series, but I can send it if there's any interest in it. Anyway, the patches in this series are complete enough on their own. With the exception of the last patch, they're all bugfixes. Cheers, Eneas Eneas U de Queiroz (6): crypto: qce - fix ctr-aes-qce block, chunk sizes crypto: qce - fix xts-aes-qce key sizes crypto: qce - save a sg table slot for result buf crypto: qce - update the skcipher IV crypto: qce - initialize fallback only for AES crypto: qce - allow building only hashes/ciphers drivers/crypto/Kconfig | 63 ++++++++- drivers/crypto/qce/Makefile | 7 +- drivers/crypto/qce/common.c | 244 ++++++++++++++++++---------------- drivers/crypto/qce/core.c | 4 + drivers/crypto/qce/dma.c | 6 +- drivers/crypto/qce/dma.h | 3 +- drivers/crypto/qce/skcipher.c | 41 ++++-- 7 files changed, 229 insertions(+), 139 deletions(-)
