Thanks Ard,
data size 1073741824 in range, less than 4294967295.
That was produced by this block.
if (tc->exp_len > __UINT32_MAX__) {
printk("data too large\n");
}
else {
printk("data size %lld in range, less than %u.\n", tc->exp_len, __UINT32_MAX__);
}
Looks like 1 and 2 gig messages should work.
________________________________________
From: Ard Biesheuvel <ardb@xxxxxxxxxx>
Sent: Wednesday, September 11, 2024 9:50 AM
To: Jeff Barnes
Cc: linux-crypto@xxxxxxxxxxxxxxx
Subject: [EXTERNAL] Re: Incorrect SHA Returned from crypto_shash_digest
[You don't often get email from ardb@xxxxxxxxxx. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
On Wed, 11 Sept 2024 at 15:17, Jeff Barnes <jeffbarnes@xxxxxxxxxxxxx> wrote:
>
> Hello,
>
> **Environment:**
> - Kernel v6.6.14
> - x86
>
> I am currently refactoring an ACVP test harness kernel module for an upcoming FIPS certification. We are certifying the kernel SHA3 implementation, so I have added test handling code for SHA3 to the module. While the Monte Carlo tests and functional tests are providing correct output for SHA3, the Large Data Tests (LDT) are failing. Below is a snippet of the code I added for LDT with error handling removed for clarity. The sdesc was created elsewhere in the code.
>
> unsigned char *large_data = NULL;
> unsigned long long int cp_size = tc->msg_len;
>
> large_data = (unsigned char *)vmalloc(tc->exp_len); /* 1, 2, 4 or 8 Gig */
> cp_size = tc->msg_len;
> // Expand the test case message to the full size of the large_data object
> memcpy(large_data, tc->msg, cp_size);
> while (cp_size * 2 <= tc->exp_len) {
> memcpy(large_data + cp_size, large_data, cp_size);
> cp_size *= 2;
> }
> if (tc->exp_len - cp_size > 0) memcpy(large_data + cp_size, large_data, tc->exp_len - cp_size);
> err = crypto_shash_digest(sdesc, large_data, tc->exp_len, tc->md);
>
> if (large_data) vfree(large_data);
>
> I verified that large_data has the expected data with printk's.
>
> I also tried using update/final with smaller large_data sizes, but I get the same incorrect SHA in _final as from _digest. When I run the equivalent test with libkcapi, I get the correct md. It seems the kernel needs data this large to be sent by send/vmsplice in userspace for this to work. Is this correct?
>
> Any help would be appreciated.
>
Hi Jeff,
AFAIK the crypto APIs generally don't support inputs larger than U32_MAX.
