bitcoin-opencl fails self test on Arc B60

[ukasz]

I am not convinced this is caused by JtR alone, so this bug is just a heads up.
Bitcoin opencl format is failing self test on Intel GPUs, unless we limit LWS to 14 or smaller.
Here is an example on Arc B60:

$ ./john -test -format=bitcoin-opencl
Bitcoin-opencl
Device 1: Intel(R) Arc(TM) Pro B60 Graphics
Benchmarking: Bitcoin-opencl, Bitcoin Core [SHA512 AES OpenCL]... FAILED (cmp_all(1))

$ LWS=14  ./john -test -format=bitcoin-opencl
Device 1: Intel(R) Arc(TM) Pro B60 Graphics
Benchmarking: Bitcoin-opencl, Bitcoin Core [SHA512 AES OpenCL]...(1280 blocks)
DONE
Speed for cost 1 (iteration count) of 200460
Raw:    2333 c/s real, 2327 c/s virtual

[ukasz]

Same for Lunar Lake 258V, it works for LWS=14, fails for 15. General behavior is that we have 0 in results (cracked array) after first crypt_all.

[ukasz]

I reported that to Intel's OpenCL runtime and they pointed out that kernel's input is not initialized when count in crypt_all() is smaller than GWS. They suggested something like this to fix it:

static int crypt_all(int *pcount, struct db_salt *salt)
{
        const int count = *pcount;
        size_t *lws = local_work_size ? &local_work_size : NULL;
        global_work_size = GET_NEXT_MULTIPLE(count, local_work_size);

        in_size = sizeof(password_t) * global_work_size;
        cracked_size = sizeof(*cracked) * global_work_size;

        if (new_keys)
        {
               + if (global_work_size > (size_t)count)
               +        memset(&saved_key[count], 0, (global_work_size - count) * sizeof(password_t));

[ukasz]

I tested a similar workaround on phpass-opencl which is also failing on B60 (but not on Lunar Lake 258V), self test still failed, but went a bit further (trying 317 keys instead of 5). I still don't quite understand how first call of crypt_all could be affected by this bug if we allocate memory by calloc. Does self test initialize input array beyond count?

[solardiz]

Thank you very much, @ukasz! I'll hopefully have time to take a look later - unfortunately, I'm generally in a lack of time lately.

I wonder if you, your colleagues, and this finding could help us figure out some of the other failures seen on Intel cards, see #5876 - for a start, you could want to check whether you're seeing the same failures or not.

[ukasz]

I'll try to keep an eye on formats failing on Intel GPUs if anything comes up. A770 is quite rare, old and I don't have access to it at the moment, so it may be harder to nail it down. On B70 I saw 4 format failures, one already (ethereum-opencl) ended up beeing a bug in IGC, so I guess there is a mutual benefit of looking at failures. Canonical is quite slow at upgrading intel packages, so some of the failures can be related to old drivers, ethereum was fixed a few days ago, but it will take months to land in the distro. In general it is better to use packages (especialy igc and opencl-runtime) from intel github repositories.