Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 19 Apr 2023 17:53:53 -0400
From:   Scott Mayhew <smayhew@redhat.com>
To:     linux-crypto@vger.kernel.org
Cc:     chuck.lever@oracle.com, linux-nfs@vger.kernel.org
Subject: RPCSEC GSS krb5 KUnit test fails on arm64 with h/w accelerated
 ciphers enabled
Message-ID: <ZEBi8ReG9LKLcmW3@aion.usersys.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Precedence: bulk

Chuck's recently-added RPCSEC GSS krb5 KUnit test
(net/sunrpc/auth_gss/gss_krb5_test.c) is failing on arm64, specifically
the RFC 3962 test cases (I'm just pasting the output of 1 case, but all
6 cases fail):

---8<---
[  237.255197]         # Subtest: RFC 3962 encryption
[  237.255588]     # RFC 3962 encryption: EXPECTATION FAILED at net/sunrpc/auth_gss/gss_krb5_test.c:772
                   Expected memcmp(param->next_iv->data, iv, param->next_iv->len) == 0, but
                       memcmp(param->next_iv->data, iv, param->next_iv->len) == 1 (0x1)
               
               IV mismatch
---8<---

If I disable the hardware accelerated ciphers
(CONFIG_CRYPTO_AES_ARM64_CE_BLK and CONFIG_CRYPTO_AES_ARM64_NEON_BLK),
then the test works.

Likewise, if I modify Chuck's test to explicitly request
"cts(cbc(aes-generic))", then the test works.

The problem is that the asm helper aes_cbc_cts_encrypt in
arch/arm64/crypto/aes-modes.S doesn't return the next IV.

If I make the following change, then the test works:

diff --git a/arch/arm64/crypto/aes-modes.S b/arch/arm64/crypto/aes-modes.S
index 0e834a2c062c..477605fad76b 100644
--- a/arch/arm64/crypto/aes-modes.S
+++ b/arch/arm64/crypto/aes-modes.S
@@ -268,6 +268,7 @@ AES_FUNC_START(aes_cbc_cts_encrypt)
 	add		x4, x0, x4
 	st1		{v0.16b}, [x4]			/* overlapping stores */
 	st1		{v1.16b}, [x0]
+	st1		{v1.16b}, [x5]
 	ret
 AES_FUNC_END(aes_cbc_cts_encrypt)

But I don't know if that change is at all correct! (I've never even
looked at arm64 asm before).  If someone who's knowledgeable about this
code could chime in, I'd appreciate it.

-Scott