Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Eneas U de Queiroz <cotequeiroz@gmail.com>
To:     Herbert Xu <herbert@gondor.apana.org.au>,
        "David S. Miller" <davem@davemloft.net>,
        linux-crypto@vger.kernel.org
Cc:     Eneas U de Queiroz <cotequeiroz@gmail.com>
Subject: Subject: [PATCH 0/6] crypto: QCE hw-crypto fixes
Date:   Fri, 20 Dec 2019 16:02:12 -0300
Message-Id: <20191220190218.28884-1-cotequeiroz@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

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(-)