On Fri, Dec 20, 2019 at 04:02:12PM -0300, Eneas U de Queiroz wrote: > 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(-) All applied. Thanks. -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
