On Mon, Jun 30, 2025 at 08:26:34AM +0200, Ingo Franzki wrote:
On 27.06.2025 20:56, Eric Biggers wrote:
Commit 88c02b3f79a6 ("s390/sha3: Support sha3 performance enhancements") added the field s390_sha_ctx::first_message_part and made it be used by s390_sha_update_blocks(). At the time, s390_sha_update_blocks() was used by all the s390 SHA-1, SHA-2, and SHA-3 algorithms. However, only the initialization functions for SHA-3 were updated, leaving SHA-1 and SHA-2 using first_message_part uninitialized.
This could cause e.g. CPACF_KIMD_SHA_512 | CPACF_KIMD_NIP to be used instead of just CPACF_KIMD_NIP. It's unclear why this didn't cause a problem earlier;
The NIP flag is only recognized by the SHA3 function codes if the KIMD instruction, for the others (SHA1 and SHA2) it is ignored.
Ah, that explains it then.
uninitialized boolean. Perhaps the CPU ignores CPACF_KIMD_NIP for SHA-1 and SHA-2. Regardless, let's fix this. For now just initialize to false, i.e. don't try to "optimize" the SHA state initialization.
Note: in 6.16, we need to patch SHA-1, SHA-384, and SHA-512. In 6.15 and earlier, we'll also need to patch SHA-224 and SHA-256, as they hadn't yet been librarified (which incidentally fixed this bug).
Fixes: 88c02b3f79a6 ("s390/sha3: Support sha3 performance enhancements")
If this patch is applied on 88c02b3f79a6 then the first_message_part field should probably set to 0 instead of false, since only since commit 7b83638f962c30cb6271b5698dc52cdf9b638b48 "crypto: s390/sha1 - Use API partial block handling" first_message_part is a bool, before it was an int.
Yes, when backporting this patch to 6.15 and 6.12 there will be 2 things that I'll change:
1. Extend it to cover SHA-224 and SHA-256 (which had been reworked in 6.16) 2. Change false to 0
- Eric