CI: Selftest failures of s390 SHA3 and HMAC on next kernel

CI: Selftest failures of s390 SHA3 and HMAC on next kernel

[Ingo Franzki]

Hi Herbert,

in tonight's CI run the self-tests of the s390x kernel ciphers for SHA-3 and HMAC (with SHA-2) started to fail on the next kernel.
This must be something the came into the next kernel just recently (yesterday). It did not fail before tonight.

Affected modules: sha3_512_s390, sha3_256_s390, and hmac_s390.
Not affected are: sha512_s390 and sha1_s390. 
sha256/sha224 no longer exist as module, probably due to the move to be a library now. 
All SHA-2 digest self-tests pass, but strangely, the HMAC with SHA-2 self-tests fail....

May 22 15:58:54 b3545036.lnxne.boe kernel: alg: ahash: hmac_s390_sha224 test failed (wrong result) on test vector "random: psize=0 ksize=131", cfg="random: may_sleep use_final src_divs=[<reimport>100.0%@+172] dst_divs=[89.63%@+2522, 8.1%@+19, 2.36%@+3988]"
May 22 15:58:54 b3545036.lnxne.boe kernel: alg: self-tests for hmac(sha224) using hmac_s390_sha224 failed (rc=-22)

May 22 15:58:54 b3545036.lnxne.boe kernel: alg: ahash: hmac_s390_sha256 test failed (wrong result) on test vector "random: psize=512 ksize=80", cfg="random: may_sleep use_final src_divs=[100.0%@+4080] iv_offset=88 key_offset=98"
May 22 15:58:54 b3545036.lnxne.boe kernel: alg: self-tests for hmac(sha256) using hmac_s390_sha256 failed (rc=-22)

May 22 15:58:54 b3545036.lnxne.boe kernel: alg: ahash: hmac_s390_sha384 test failed (wrong result) on test vector "random: psize=64 ksize=131", cfg="random: use_final nosimd src_divs=[90.40%@+29, 9.60%@+3750] iv_offset=111 key_offset=9"
May 22 15:58:54 b3545036.lnxne.boe kernel: alg: self-tests for hmac(sha384) using hmac_s390_sha384 failed (rc=-22)

May 22 15:58:54 b3545036.lnxne.boe kernel: alg: ahash: hmac_s390_sha512 test failed (wrong result) on test vector "random: psize=1556 ksize=7", cfg="random: use_final nosimd src_divs=[<reimport,nosimd>100.0%@+10] iv_offset=15"
May 22 15:58:54 b3545036.lnxne.boe kernel: alg: self-tests for hmac(sha512) using hmac_s390_sha512 failed (rc=-22)

May 22 15:59:44 b3545036.lnxne.boe kernel: alg: ahash: sha3-224-s390 test failed (wrong result) on test vector "random: psize=388 ksize=0", cfg="random: may_sleep use_final src_divs=[<flush>100.0%@+2585] key_offset=82"
May 22 15:59:44 b3545036.lnxne.boe kernel: alg: self-tests for sha3-224 using sha3-224-s390 failed (rc=-22)

May 22 15:59:44 b3545036.lnxne.boe kernel: alg: ahash: sha3-256-s390 test failed (wrong result) on test vector "random: psize=512 ksize=0", cfg="random: inplace_two_sglists use_final src_divs=[<reimport>89.54%@+3198, 5.23%@+5, 5.23%@+974] key_offset=46"
May 22 15:59:44 b3545036.lnxne.boe kernel: alg: self-tests for sha3-256 using sha3-256-s390 failed (rc=-22)

May 22 16:00:13 b3545036.lnxne.boe kernel: alg: ahash: sha3-384-s390 test failed (wrong result) on test vector "random: psize=2667 ksize=0", cfg="random: may_sleep use_final src_divs=[<flush>100.0%@+15] dst_divs=[100.0%@+275]"
May 22 16:00:13 b3545036.lnxne.boe kernel: alg: self-tests for sha3-384 using sha3-384-s390 failed (rc=-22)

May 22 16:00:13 b3545036.lnxne.boe kernel: alg: ahash: sha3-512-s390 test failed (wrong result) on test vector "random: psize=983 ksize=0", cfg="random: inplace_two_sglists use_final nosimd src_divs=[<flush>100.0%@+4]"
May 22 16:00:13 b3545036.lnxne.boe kernel: alg: self-tests for sha3-512 using sha3-512-s390 failed (rc=-22)

-- 
Ingo Franzki
eMail: ifranzki@linux.ibm.com  
Tel: ++49 (0)7031-16-4648
Linux on IBM Z Development, Schoenaicher Str. 220, 71032 Boeblingen, Germany

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Gregor Pillen
Geschäftsführung: David Faller
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM DATA Privacy Statement: https://www.ibm.com/privacy/us/en/

Re: CI: Selftest failures of s390 SHA3 and HMAC on next kernel

[Herbert Xu]

On Thu, May 22, 2025 at 04:13:59PM +0200, Ingo Franzki wrote:
> Hi Herbert,
> 
> in tonight's CI run the self-tests of the s390x kernel ciphers for SHA-3 and HMAC (with SHA-2) started to fail on the next kernel.
> This must be something the came into the next kernel just recently (yesterday). It did not fail before tonight.
> 
> Affected modules: sha3_512_s390, sha3_256_s390, and hmac_s390.
> Not affected are: sha512_s390 and sha1_s390. 
> sha256/sha224 no longer exist as module, probably due to the move to be a library now. 
> All SHA-2 digest self-tests pass, but strangely, the HMAC with SHA-2 self-tests fail....

It's probably the export/import format tests.  Please try reverting

	18c438b228558e05ede7dccf947a6547516fc0c7

and see if the problem goes away.  If it does then I'll revert that
for now and figure out why the s390 export format is still different.

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: CI: Selftest failures of s390 SHA3 and HMAC on next kernel

[Ingo Franzki]

On 23.05.2025 07:51, Herbert Xu wrote:
> On Thu, May 22, 2025 at 04:13:59PM +0200, Ingo Franzki wrote:
>> Hi Herbert,
>>
>> in tonight's CI run the self-tests of the s390x kernel ciphers for SHA-3 and HMAC (with SHA-2) started to fail on the next kernel.
>> This must be something the came into the next kernel just recently (yesterday). It did not fail before tonight.
>>
>> Affected modules: sha3_512_s390, sha3_256_s390, and hmac_s390.
>> Not affected are: sha512_s390 and sha1_s390. 
>> sha256/sha224 no longer exist as module, probably due to the move to be a library now. 
>> All SHA-2 digest self-tests pass, but strangely, the HMAC with SHA-2 self-tests fail....
> 
> It's probably the export/import format tests.  Please try reverting
> 
> 	18c438b228558e05ede7dccf947a6547516fc0c7
> 
> and see if the problem goes away.  If it does then I'll revert that
> for now and figure out why the s390 export format is still different.

Yes, indeed, reverting this commit makes the problem to go away. 

> 
> Thanks,


-- 
Ingo Franzki
eMail: ifranzki@linux.ibm.com  
Tel: ++49 (0)7031-16-4648
Linux on IBM Z Development, Schoenaicher Str. 220, 71032 Boeblingen, Germany

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Gregor Pillen
Geschäftsführung: David Faller
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM DATA Privacy Statement: https://www.ibm.com/privacy/us/en/

[PATCH] crypto: s390/hmac - Fix counter in export state

[Herbert Xu]

On Fri, May 23, 2025 at 10:02:18AM +0200, Ingo Franzki wrote:
> 
> Yes, indeed, reverting this commit makes the problem to go away. 

Great.  While I've got your attenttion, could you also test this
patch to see if it makes the hmac errors go away?

Thanks,

---8<---
The hmac export state needs to be one block-size bigger to account
for the ipad.

Reported-by: Ingo Franzki <ifranzki@linux.ibm.com>
Fixes: 08811169ac01 ("crypto: s390/hmac - Use API partial block handling")
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

diff --git a/arch/s390/crypto/hmac_s390.c b/arch/s390/crypto/hmac_s390.c
index 93a1098d9f8d..58444da9b004 100644
--- a/arch/s390/crypto/hmac_s390.c
+++ b/arch/s390/crypto/hmac_s390.c
@@ -290,6 +290,7 @@ static int s390_hmac_export(struct shash_desc *desc, void *out)
 	struct s390_kmac_sha2_ctx *ctx = shash_desc_ctx(desc);
 	unsigned int bs = crypto_shash_blocksize(desc->tfm);
 	unsigned int ds = bs / 2;
+	u64 lo = ctx->buflen[0];
 	union {
 		u8 *u8;
 		u64 *u64;
@@ -301,9 +302,10 @@ static int s390_hmac_export(struct shash_desc *desc, void *out)
 	else
 		memcpy(p.u8, ctx->param, ds);
 	p.u8 += ds;
-	put_unaligned(ctx->buflen[0], p.u64++);
+	lo += bs;
+	put_unaligned(lo, p.u64++);
 	if (ds == SHA512_DIGEST_SIZE)
-		put_unaligned(ctx->buflen[1], p.u64);
+		put_unaligned(ctx->buflen[1] + (lo < bs), p.u64);
 	return err;
 }
 
@@ -316,14 +318,16 @@ static int s390_hmac_import(struct shash_desc *desc, const void *in)
 		const u8 *u8;
 		const u64 *u64;
 	} p = { .u8 = in };
+	u64 lo;
 	int err;
 
 	err = s390_hmac_sha2_init(desc);
 	memcpy(ctx->param, p.u8, ds);
 	p.u8 += ds;
-	ctx->buflen[0] = get_unaligned(p.u64++);
+	lo = get_unaligned(p.u64++);
+	ctx->buflen[0] = lo - bs;
 	if (ds == SHA512_DIGEST_SIZE)
-		ctx->buflen[1] = get_unaligned(p.u64);
+		ctx->buflen[1] = get_unaligned(p.u64) - (lo < bs);
 	if (ctx->buflen[0] | ctx->buflen[1])
 		ctx->gr0.ikp = 1;
 	return err;
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: s390/hmac - Fix counter in export state

[Ingo Franzki]

On 23.05.2025 13:24, Herbert Xu wrote:
> On Fri, May 23, 2025 at 10:02:18AM +0200, Ingo Franzki wrote:
>>
>> Yes, indeed, reverting this commit makes the problem to go away. 
> 
> Great.  While I've got your attenttion, could you also test this
> patch to see if it makes the hmac errors go away?

Yes, with your fix below and with commit 18c438b228558e05ede7dccf947a6547516fc0c7 the HMAC failures are no longer seen, but the SHA3 failures are still there (I guess that's as you have expected it). 

> 
> Thanks,
> 
> ---8<---
> The hmac export state needs to be one block-size bigger to account
> for the ipad.
> 
> Reported-by: Ingo Franzki <ifranzki@linux.ibm.com>
> Fixes: 08811169ac01 ("crypto: s390/hmac - Use API partial block handling")
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> 
> diff --git a/arch/s390/crypto/hmac_s390.c b/arch/s390/crypto/hmac_s390.c
> index 93a1098d9f8d..58444da9b004 100644
> --- a/arch/s390/crypto/hmac_s390.c
> +++ b/arch/s390/crypto/hmac_s390.c
> @@ -290,6 +290,7 @@ static int s390_hmac_export(struct shash_desc *desc, void *out)
>  	struct s390_kmac_sha2_ctx *ctx = shash_desc_ctx(desc);
>  	unsigned int bs = crypto_shash_blocksize(desc->tfm);
>  	unsigned int ds = bs / 2;
> +	u64 lo = ctx->buflen[0];
>  	union {
>  		u8 *u8;
>  		u64 *u64;
> @@ -301,9 +302,10 @@ static int s390_hmac_export(struct shash_desc *desc, void *out)
>  	else
>  		memcpy(p.u8, ctx->param, ds);
>  	p.u8 += ds;
> -	put_unaligned(ctx->buflen[0], p.u64++);
> +	lo += bs;
> +	put_unaligned(lo, p.u64++);
>  	if (ds == SHA512_DIGEST_SIZE)
> -		put_unaligned(ctx->buflen[1], p.u64);
> +		put_unaligned(ctx->buflen[1] + (lo < bs), p.u64);
>  	return err;
>  }
>  
> @@ -316,14 +318,16 @@ static int s390_hmac_import(struct shash_desc *desc, const void *in)
>  		const u8 *u8;
>  		const u64 *u64;
>  	} p = { .u8 = in };
> +	u64 lo;
>  	int err;
>  
>  	err = s390_hmac_sha2_init(desc);
>  	memcpy(ctx->param, p.u8, ds);
>  	p.u8 += ds;
> -	ctx->buflen[0] = get_unaligned(p.u64++);
> +	lo = get_unaligned(p.u64++);
> +	ctx->buflen[0] = lo - bs;
>  	if (ds == SHA512_DIGEST_SIZE)
> -		ctx->buflen[1] = get_unaligned(p.u64);
> +		ctx->buflen[1] = get_unaligned(p.u64) - (lo < bs);
>  	if (ctx->buflen[0] | ctx->buflen[1])
>  		ctx->gr0.ikp = 1;
>  	return err;


-- 
Ingo Franzki
eMail: ifranzki@linux.ibm.com  
Tel: ++49 (0)7031-16-4648
Linux on IBM Z Development, Schoenaicher Str. 220, 71032 Boeblingen, Germany

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Gregor Pillen
Geschäftsführung: David Faller
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM DATA Privacy Statement: https://www.ibm.com/privacy/us/en/

Re: CI: Selftest failures of s390 SHA3 and HMAC on next kernel

[Herbert Xu]

On Thu, May 22, 2025 at 04:13:59PM +0200, Ingo Franzki wrote:
>
> May 22 15:59:44 b3545036.lnxne.boe kernel: alg: ahash: sha3-224-s390 test failed (wrong result) on test vector "random: psize=388 ksize=0", cfg="random: may_sleep use_final src_divs=[<flush>100.0%@+2585] key_offset=82"
> May 22 15:59:44 b3545036.lnxne.boe kernel: alg: self-tests for sha3-224 using sha3-224-s390 failed (rc=-22)

I have no idea what's going on with the sha3 export state, perhaps
the hardware just stores things in a different byte-order?

Please apply this debugging patch and send me the results on s390.
It goes on top of commit 0413bcf0fc460a68a2a7a8354aee833293d7d693.
If you've already reverted 18c438b228558e05ede7dccf947a6547516fc0c7
you would need to reapply it first.

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 737064b31480..42aaf2e7c164 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -158,7 +158,7 @@ struct alg_test_desc {
 	} suite;
 };
 
-static void hexdump(unsigned char *buf, unsigned int len)
+static void hexdump(const unsigned char *buf, unsigned int len)
 {
 	print_hex_dump(KERN_CONT, "", DUMP_PREFIX_OFFSET,
 			16, 1,
@@ -1485,6 +1485,11 @@ static int check_ahash_export(struct ahash_request *req,
 		       driver, err, vec_name, cfg->name);
 		return err;
 	}
+	if (!memcmp(driver, "sha3", 4) && memcmp(hashstate, vec->state, 200)) {
+		pr_err("alg: ahash: sha3 export state different from generic: %s\n", driver);
+		hexdump(vec->state, 200);
+		hexdump(hashstate, 200);
+	}
 	err = crypto_ahash_import(req, vec->state);
 	if (err) {
 		pr_err("alg: ahash: %s mixed import() failed with err %d on test vector %s, cfg=\"%s\"\n",

Re: CI: Selftest failures of s390 SHA3 and HMAC on next kernel

[Ingo Franzki]

[-- Attachment #1: Type: text/plain, Size: 8231 bytes --]

On 23.05.2025 13:41, Herbert Xu wrote:
> On Thu, May 22, 2025 at 04:13:59PM +0200, Ingo Franzki wrote:
>>
>> May 22 15:59:44 b3545036.lnxne.boe kernel: alg: ahash: sha3-224-s390 test failed (wrong result) on test vector "random: psize=388 ksize=0", cfg="random: may_sleep use_final src_divs=[<flush>100.0%@+2585] key_offset=82"
>> May 22 15:59:44 b3545036.lnxne.boe kernel: alg: self-tests for sha3-224 using sha3-224-s390 failed (rc=-22)
> 
> I have no idea what's going on with the sha3 export state, perhaps
> the hardware just stores things in a different byte-order?

The IBM Z principle of operations manual states for KIMD with SHA3 function code:

"A 200-byte intermediate message digest is generated for the 136-byte message blocks in operand 2
using the KECCAK[c] algorithm with the 200-byte initial chaining value in the parameter block. The generated
intermediate message digest, also called the output chaining value (OCV), is stored in the chaining-
value field of the parameter block. See programming note 10 on page 7-202 regarding the
numbering of the bits in the parameter block and second operand as compared with the numbering of the
bits in the state array."

For the text of note 10 on page 7-202 see screenshots attached (contains a graphic, so not possible to just copy &  paste it).

> 
> Please apply this debugging patch and send me the results on s390.
> It goes on top of commit 0413bcf0fc460a68a2a7a8354aee833293d7d693.
> If you've already reverted 18c438b228558e05ede7dccf947a6547516fc0c7
> you would need to reapply it first.

Here is the output from modprobing sha3_256_s390:
I guess the output is somehow interleaved, since both sha3-224 and sha3-256 are tested concurrently.....
I hope you can sort it out what belongs to what.

May 23 13:50:09 b8345006.lnxne.boe kernel: alg: ahash: sha3 export state different from generic: sha3-256-s390
May 23 13:50:09 b8345006.lnxne.boe kernel: alg: ahash: sha3 export state different from generic: sha3-224-s390
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000000: 82 b2 3c 2d 20 76 43 a5 08 dd 0f 8e 75 dc ac a1
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000000: 91 f7 19 50 95 49 c0 ab a7 02 e3 61 55 80 ef b3
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000010: d3 aa 7a db f8 d1 da 66 36 e5 d5 7f c8 60 58 c1
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000020: dd 5a 0f 18 8b f6 13 8f e3 5d ef 3b da e8 b5 93
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000010: af ce 61 40 0d 81 6b c5 5d 6a b9 6c b7 af f9 b0
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000030: 7e 6b b3 2e 37 c3 99 f5 bf c6 3b 6e 04 6d 5e fb
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000020: 08 cc b1 cb 31 58 4b 2d d9 bf 6f 1c 79 cf d6 ca
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000040: 17 42 44 08 53 6d 48 23 59 2d 8e f0 37 0d 20 87
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000030: ce f0 95 67 c0 af 8c c1 ff 49 9b 17 ca 32 b8 4f
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000050: cb 87 72 42 bd db d6 65 4c d3 9d 2b b0 b4 66 ad
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000040: 87 5e 74 43 37 ed 5f ae d7 3a f4 8b 76 4e 04 f1
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000060: 62 5d be c3 88 9d 0a c9 f7 20 61 2b 16 6e 0a a3
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000050: 34 a9 0e b2 72 f3 34 0d e0 a6 00 97 a0 17 ca 2e
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000070: 20 43 90 11 d9 e4 e1 2d 11 46 f8 65 79 53 2e c6
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000080: da 56 b5 d2 e8 c2 df eb 3c 78 74 e5 13 0a d7 9c
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000090: 00 16 e5 ae 5f 66 ec 17 3f 1c de 84 73 68 f4 1e
May 23 13:50:09 b8345006.lnxne.boe kernel: 000000a0: 1c f5 0f 1f 42 d5 2d ed 73 61 9f 18 c2 23 69 fb
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000060: 90 5f cc 65 89 3c 50 77 04 e7 f3 9c 7c 47 9c 12
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000070: 00 84 01 98 32 d0 5a 81 7d 07 5b 4e 8b 76 39 fe
May 23 13:50:09 b8345006.lnxne.boe kernel: 000000b0: 3c 2f b6 60 37 0c a1 5b a6 1f cc 12 19 a4 28 8c
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000080: 9a e6 a8 d9 cf d1 c9 e5 d4 c7 28 f7 e0 64 94 b3
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000090: a4 58 45 f8 bf 4c 18 fe 89 30 f0 3c 8f 28 58 b3
May 23 13:50:09 b8345006.lnxne.boe kernel: 000000a0: c9 16 ef dc 22 fb f6 f3 88 db 3f 28 1f f4 c3 b7
May 23 13:50:09 b8345006.lnxne.boe kernel: 000000c0: a3 ba 70 b3 a2 bb 6d 62
May 23 13:50:09 b8345006.lnxne.boe kernel: 000000b0: 03 0a 4f 74 6c 9e 0b 9f 08 05 f9 24 32 1e 67 6d
May 23 13:50:09 b8345006.lnxne.boe kernel: 000000c0: 06 78 41 40 6e 5e f3 e4
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000000: a5 43 76 20 2d 3c b2 82 a1 ac dc 75 8e 0f dd 08
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000000: ab c0 49 95 50 19 f7 91 b3 ef 80 55 61 e3 02 a7
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000010: c5 6b 81 0d 40 61 ce af b0 f9 af b7 6c b9 6a 5d
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000020: 2d 4b 58 31 cb b1 cc 08 ca d6 cf 79 1c 6f bf d9
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000030: c1 8c af c0 67 95 f0 ce 4f b8 32 ca 17 9b 49 ff
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000010: 66 da d1 f8 db 7a aa d3 c1 58 60 c8 7f d5 e5 36
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000040: ae 5f ed 37 43 74 5e 87 f1 04 4e 76 8b f4 3a d7
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000020: 8f 13 f6 8b 18 0f 5a dd 93 b5 e8 da 3b ef 5d e3
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000050: 0d 34 f3 72 b2 0e a9 34 2e ca 17 a0 97 00 a6 e0
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000060: 77 50 3c 89 65 cc 5f 90 12 9c 47 7c 9c f3 e7 04
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000070: 81 5a d0 32 98 01 84 00 fe 39 76 8b 4e 5b 07 7d
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000080: e5 c9 d1 cf d9 a8 e6 9a b3 94 64 e0 f7 28 c7 d4
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000030: f5 99 c3 37 2e b3 6b 7e fb 5e 6d 04 6e 3b c6 bf
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000090: fe 18 4c bf f8 45 58 a4 b3 58 28 8f 3c f0 30 89
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000040: 23 48 6d 53 08 44 42 17 87 20 0d 37 f0 8e 2d 59
May 23 13:50:09 b8345006.lnxne.boe kernel: 000000a0: f3 f6 fb 22 dc ef 16 c9 b7 c3 f4 1f 28 3f db 88
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000050: 65 d6 db bd 42 72 87 cb ad 66 b4 b0 2b 9d d3 4c
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000060: c9 0a 9d 88 c3 be 5d 62 a3 0a 6e 16 2b 61 20 f7
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000070: 2d e1 e4 d9 11 90 43 20 c6 2e 53 79 65 f8 46 11
May 23 13:50:09 b8345006.lnxne.boe kernel: 000000b0: 9f 0b 9e 6c 74 4f 0a 03 6d 67 1e 32 24 f9 05 08
May 23 13:50:09 b8345006.lnxne.boe kernel: 000000c0: e4 f3 5e 6e 40 41 78 06
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000080: eb df c2 e8 d2 b5 56 da 9c d7 0a 13 e5 74 78 3c
May 23 13:50:09 b8345006.lnxne.boe kernel: 00000090: 17 ec 66 5f ae e5 16 00 1e f4 68 73 84 de 1c 3f
May 23 13:50:09 b8345006.lnxne.boe kernel: alg: ahash: sha3-256-s390 test failed (wrong result) on test vector "random: psize=4096 ksize=0", cfg="random: may_sleep use_final src_divs=[<flush>100.0%@+706] dst_divs=[100.0%@+4037] key_offset=114"
May 23 13:50:09 b8345006.lnxne.boe kernel: 000000a0: ed 2d d5 42 1f 0f f5 1c fb 69 23 c2 18 9f 61 73
May 23 13:50:09 b8345006.lnxne.boe kernel: 000000b0: 5b a1 0c 37 60 b6 2f 3c 8c 28 a4 19 12 cc 1f a6
May 23 13:50:09 b8345006.lnxne.boe kernel: 000000c0: 62 6d bb a2 b3 70 ba a3
May 23 13:50:09 b8345006.lnxne.boe kernel: alg: self-tests for sha3-256 using sha3-256-s390 failed (rc=-22)
May 23 13:50:09 b8345006.lnxne.boe kernel: alg: ahash: sha3-224-s390 test failed (wrong result) on test vector "random: psize=1536 ksize=0", cfg="random: inplace_two_sglists use_final nosimd_setkey src_divs=[83.33%@+15, <flush,nosimd>6.79%@+17, 4.94%@+4007, <reimport>4.94%@+1688] key_offset=1"


> 
> Thanks,


-- 
Ingo Franzki
eMail: ifranzki@linux.ibm.com  
Tel: ++49 (0)7031-16-4648
Linux on IBM Z Development, Schoenaicher Str. 220, 71032 Boeblingen, Germany

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Gregor Pillen
Geschäftsführung: David Faller
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM DATA Privacy Statement: https://www.ibm.com/privacy/us/en/

[-- Attachment #2: KIMD-note-10-1.png --]
[-- Type: image/png, Size: 40602 bytes --]

[-- Attachment #3: KIMD-note-10-2.png --]
[-- Type: image/png, Size: 148404 bytes --]

Re: CI: Selftest failures of s390 SHA3 and HMAC on next kernel

[Herbert Xu]

On Fri, May 23, 2025 at 02:03:23PM +0200, Ingo Franzki wrote:
>
> Here is the output from modprobing sha3_256_s390:
> I guess the output is somehow interleaved, since both sha3-224 and sha3-256 are tested concurrently.....
> I hope you can sort it out what belongs to what.

Nice :)

> May 23 13:50:09 b8345006.lnxne.boe kernel: alg: ahash: sha3 export state different from generic: sha3-256-s390
> May 23 13:50:09 b8345006.lnxne.boe kernel: alg: ahash: sha3 export state different from generic: sha3-224-s390
> May 23 13:50:09 b8345006.lnxne.boe kernel: 00000000: 82 b2 3c 2d 20 76 43 a5 08 dd 0f 8e 75 dc ac a1

...

> May 23 13:50:09 b8345006.lnxne.boe kernel: 00000000: a5 43 76 20 2d 3c b2 82 a1 ac dc 75 8e 0f dd 08

So it is the byte-order.  That should be easy to fix.

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[PATCH] crypto: s390/sha3 - Use cpu byte-order when exporting

[Herbert Xu]

On Fri, May 23, 2025 at 02:03:23PM +0200, Ingo Franzki wrote:
>
> I hope you can sort it out what belongs to what.

Please let me know if this patch works or not:

---8<---
The sha3 partial hash on s390 is in little-endian just like the
final hash.  However the generic implementation produces native
or big-endian partial hashes.

Make s390 sha3 conform to that by doing the byte-swap on export
and import.

Reported-by: Ingo Franzki <ifranzki@linux.ibm.com>
Fixes: 6f90ba706551 ("crypto: s390/sha3 - Use API partial block handling")
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

diff --git a/arch/s390/crypto/sha.h b/arch/s390/crypto/sha.h
index d757ccbce2b4..cadb4b13622a 100644
--- a/arch/s390/crypto/sha.h
+++ b/arch/s390/crypto/sha.h
@@ -27,6 +27,9 @@ struct s390_sha_ctx {
 			u64 state[SHA512_DIGEST_SIZE / sizeof(u64)];
 			u64 count_hi;
 		} sha512;
+		struct {
+			__le64 state[SHA3_STATE_SIZE / sizeof(u64)];
+		} sha3;
 	};
 	int func;		/* KIMD function to use */
 	bool first_message_part;
diff --git a/arch/s390/crypto/sha3_256_s390.c b/arch/s390/crypto/sha3_256_s390.c
index 4a7731ac6bcd..03bb4f4bab70 100644
--- a/arch/s390/crypto/sha3_256_s390.c
+++ b/arch/s390/crypto/sha3_256_s390.c
@@ -35,23 +35,33 @@ static int sha3_256_init(struct shash_desc *desc)
 static int sha3_256_export(struct shash_desc *desc, void *out)
 {
 	struct s390_sha_ctx *sctx = shash_desc_ctx(desc);
-	struct sha3_state *octx = out;
+	union {
+		u8 *u8;
+		u64 *u64;
+	} p = { .u8 = out };
+	int i;
 
 	if (sctx->first_message_part) {
-		memset(sctx->state, 0, sizeof(sctx->state));
-		sctx->first_message_part = 0;
+		memset(out, 0, SHA3_STATE_SIZE);
+		return 0;
 	}
-	memcpy(octx->st, sctx->state, sizeof(octx->st));
+	for (i = 0; i < SHA3_STATE_SIZE / 8; i++)
+		put_unaligned(le64_to_cpu(sctx->sha3.state[i]), p.u64++);
 	return 0;
 }
 
 static int sha3_256_import(struct shash_desc *desc, const void *in)
 {
 	struct s390_sha_ctx *sctx = shash_desc_ctx(desc);
-	const struct sha3_state *ictx = in;
+	union {
+		const u8 *u8;
+		const u64 *u64;
+	} p = { .u8 = in };
+	int i;
 
+	for (i = 0; i < SHA3_STATE_SIZE / 8; i++)
+		sctx->sha3.state[i] = cpu_to_le64(get_unaligned(p.u64++));
 	sctx->count = 0;
-	memcpy(sctx->state, ictx->st, sizeof(ictx->st));
 	sctx->first_message_part = 0;
 	sctx->func = CPACF_KIMD_SHA3_256;
 
diff --git a/arch/s390/crypto/sha3_512_s390.c b/arch/s390/crypto/sha3_512_s390.c
index 018f02fff444..a5c9690eecb1 100644
--- a/arch/s390/crypto/sha3_512_s390.c
+++ b/arch/s390/crypto/sha3_512_s390.c
@@ -34,24 +34,33 @@ static int sha3_512_init(struct shash_desc *desc)
 static int sha3_512_export(struct shash_desc *desc, void *out)
 {
 	struct s390_sha_ctx *sctx = shash_desc_ctx(desc);
-	struct sha3_state *octx = out;
-
+	union {
+		u8 *u8;
+		u64 *u64;
+	} p = { .u8 = out };
+	int i;
 
 	if (sctx->first_message_part) {
-		memset(sctx->state, 0, sizeof(sctx->state));
-		sctx->first_message_part = 0;
+		memset(out, 0, SHA3_STATE_SIZE);
+		return 0;
 	}
-	memcpy(octx->st, sctx->state, sizeof(octx->st));
+	for (i = 0; i < SHA3_STATE_SIZE / 8; i++)
+		put_unaligned(le64_to_cpu(sctx->sha3.state[i]), p.u64++);
 	return 0;
 }
 
 static int sha3_512_import(struct shash_desc *desc, const void *in)
 {
 	struct s390_sha_ctx *sctx = shash_desc_ctx(desc);
-	const struct sha3_state *ictx = in;
+	union {
+		const u8 *u8;
+		const u64 *u64;
+	} p = { .u8 = in };
+	int i;
 
+	for (i = 0; i < SHA3_STATE_SIZE / 8; i++)
+		sctx->sha3.state[i] = cpu_to_le64(get_unaligned(p.u64++));
 	sctx->count = 0;
-	memcpy(sctx->state, ictx->st, sizeof(ictx->st));
 	sctx->first_message_part = 0;
 	sctx->func = CPACF_KIMD_SHA3_512;
 
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: s390/sha3 - Use cpu byte-order when exporting

[Ingo Franzki]

On 23.05.2025 14:28, Herbert Xu wrote:
> On Fri, May 23, 2025 at 02:03:23PM +0200, Ingo Franzki wrote:
>>
>> I hope you can sort it out what belongs to what.
> 
> Please let me know if this patch works or not:

Yes this fixes the selftest failures.

However, I am not sure if the handling of the first_message_part field is correct (or even was correct before your fix).
The first_message_part is essentially there to control the setting of the NIP (No-ICV-Parameter) flag for the KIMD and KLMD instructions in s390_sha_update() and s390_sha_final() in arch/s390/crypto/sha_common.c. That NIP flag is only supported when MSA 12 is available (facility 86). 

It must be 1 until the very first KIMD or KLMD call has been done, and must be resetted to zero afterwards. 
If NIP is set then you can omit the zeroing out of the initial parameter block. This saves a few cycles for the memset, but also for transferring the (all zero) IV to the coprocessor. 

All seems OK, unless that you always set first_message_part to zero at import. So even if an initial state was exported, after an import first_message_part is off. Previous code did retain the stat of the first_message_part field in the exported state as well. 
OK, one can argue that this loss of performance improvement is negligible for a saved initial state situation.....

> 
> ---8<---
> The sha3 partial hash on s390 is in little-endian just like the
> final hash.  However the generic implementation produces native
> or big-endian partial hashes.
> 
> Make s390 sha3 conform to that by doing the byte-swap on export
> and import.
> 
> Reported-by: Ingo Franzki <ifranzki@linux.ibm.com>
> Fixes: 6f90ba706551 ("crypto: s390/sha3 - Use API partial block handling")
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> 
> diff --git a/arch/s390/crypto/sha.h b/arch/s390/crypto/sha.h
> index d757ccbce2b4..cadb4b13622a 100644
> --- a/arch/s390/crypto/sha.h
> +++ b/arch/s390/crypto/sha.h
> @@ -27,6 +27,9 @@ struct s390_sha_ctx {
>  			u64 state[SHA512_DIGEST_SIZE / sizeof(u64)];
>  			u64 count_hi;
>  		} sha512;
> +		struct {
> +			__le64 state[SHA3_STATE_SIZE / sizeof(u64)];
> +		} sha3;
>  	};
>  	int func;		/* KIMD function to use */
>  	bool first_message_part;
> diff --git a/arch/s390/crypto/sha3_256_s390.c b/arch/s390/crypto/sha3_256_s390.c
> index 4a7731ac6bcd..03bb4f4bab70 100644
> --- a/arch/s390/crypto/sha3_256_s390.c
> +++ b/arch/s390/crypto/sha3_256_s390.c
> @@ -35,23 +35,33 @@ static int sha3_256_init(struct shash_desc *desc)
>  static int sha3_256_export(struct shash_desc *desc, void *out)
>  {
>  	struct s390_sha_ctx *sctx = shash_desc_ctx(desc);
> -	struct sha3_state *octx = out;
> +	union {
> +		u8 *u8;
> +		u64 *u64;
> +	} p = { .u8 = out };
> +	int i;
>  
>  	if (sctx->first_message_part) {
> -		memset(sctx->state, 0, sizeof(sctx->state));
> -		sctx->first_message_part = 0;
> +		memset(out, 0, SHA3_STATE_SIZE);
> +		return 0;
>  	}
> -	memcpy(octx->st, sctx->state, sizeof(octx->st));
> +	for (i = 0; i < SHA3_STATE_SIZE / 8; i++)
> +		put_unaligned(le64_to_cpu(sctx->sha3.state[i]), p.u64++);
>  	return 0;
>  }
>  
>  static int sha3_256_import(struct shash_desc *desc, const void *in)
>  {
>  	struct s390_sha_ctx *sctx = shash_desc_ctx(desc);
> -	const struct sha3_state *ictx = in;
> +	union {
> +		const u8 *u8;
> +		const u64 *u64;
> +	} p = { .u8 = in };
> +	int i;
>  
> +	for (i = 0; i < SHA3_STATE_SIZE / 8; i++)
> +		sctx->sha3.state[i] = cpu_to_le64(get_unaligned(p.u64++));
>  	sctx->count = 0;
> -	memcpy(sctx->state, ictx->st, sizeof(ictx->st));
>  	sctx->first_message_part = 0;
>  	sctx->func = CPACF_KIMD_SHA3_256;
>  
> diff --git a/arch/s390/crypto/sha3_512_s390.c b/arch/s390/crypto/sha3_512_s390.c
> index 018f02fff444..a5c9690eecb1 100644
> --- a/arch/s390/crypto/sha3_512_s390.c
> +++ b/arch/s390/crypto/sha3_512_s390.c
> @@ -34,24 +34,33 @@ static int sha3_512_init(struct shash_desc *desc)
>  static int sha3_512_export(struct shash_desc *desc, void *out)
>  {
>  	struct s390_sha_ctx *sctx = shash_desc_ctx(desc);
> -	struct sha3_state *octx = out;
> -
> +	union {
> +		u8 *u8;
> +		u64 *u64;
> +	} p = { .u8 = out };
> +	int i;
>  
>  	if (sctx->first_message_part) {
> -		memset(sctx->state, 0, sizeof(sctx->state));
> -		sctx->first_message_part = 0;
> +		memset(out, 0, SHA3_STATE_SIZE);
> +		return 0;
>  	}
> -	memcpy(octx->st, sctx->state, sizeof(octx->st));
> +	for (i = 0; i < SHA3_STATE_SIZE / 8; i++)
> +		put_unaligned(le64_to_cpu(sctx->sha3.state[i]), p.u64++);
>  	return 0;
>  }
>  
>  static int sha3_512_import(struct shash_desc *desc, const void *in)
>  {
>  	struct s390_sha_ctx *sctx = shash_desc_ctx(desc);
> -	const struct sha3_state *ictx = in;
> +	union {
> +		const u8 *u8;
> +		const u64 *u64;
> +	} p = { .u8 = in };
> +	int i;
>  
> +	for (i = 0; i < SHA3_STATE_SIZE / 8; i++)
> +		sctx->sha3.state[i] = cpu_to_le64(get_unaligned(p.u64++));
>  	sctx->count = 0;
> -	memcpy(sctx->state, ictx->st, sizeof(ictx->st));
>  	sctx->first_message_part = 0;
>  	sctx->func = CPACF_KIMD_SHA3_512;
>  


-- 
Ingo Franzki
eMail: ifranzki@linux.ibm.com  
Tel: ++49 (0)7031-16-4648
Linux on IBM Z Development, Schoenaicher Str. 220, 71032 Boeblingen, Germany

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Gregor Pillen
Geschäftsführung: David Faller
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM DATA Privacy Statement: https://www.ibm.com/privacy/us/en/

Re: [PATCH] crypto: s390/sha3 - Use cpu byte-order when exporting

[Herbert Xu]

On Fri, May 23, 2025 at 02:54:26PM +0200, Ingo Franzki wrote:
>
> All seems OK, unless that you always set first_message_part to zero at import. So even if an initial state was exported, after an import first_message_part is off. Previous code did retain the stat of the first_message_part field in the exported state as well. 
> OK, one can argue that this loss of performance improvement is negligible for a saved initial state situation.....

Yes we have to set it to zero after an import because the import
could've come from the generic sha3.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt