Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 21 Nov 2012 19:53:41 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Problems on recent AMD driver

On 21 Nov, 2012, at 19:11 , Claudio André <claudioandre.br@...il.com> wrote:

> Em 21-11-2012 15:48, magnum escreveu:
>> Also, why does it work here:
>> 
>> magnum@...r-osx:src [unstable-jumbo]$ git grep -hC5 clEnqueueMapBuffer opencl_cryptsha256_fmt.c | head
>>     pinned_saved_keys = clCreateBuffer(context[ocl_gpu_id],
>>             CL_MEM_READ_WRITE | CL_MEM_ALLOC_HOST_PTR,
>>             sizeof(sha256_password) * gws, NULL, &ret_code);
>>     HANDLE_CLERROR(ret_code, "Error creating page-locked memory pinned_saved_keys");
>> 
>>     plaintext = (sha256_password *) clEnqueueMapBuffer(queue[ocl_gpu_id],
>>             pinned_saved_keys, CL_TRUE, CL_MAP_WRITE | CL_MAP_READ, 0,
>>             sizeof(sha256_password) * gws, 0, NULL, NULL, &ret_code);
>>     HANDLE_CLERROR(ret_code, "Error mapping page-locked memory saved_plain");
>> 
>> The only difference I can see is that I use CL_MEM_READ_ONLY instead of CL_MEM_READ_WRITE. What happens if you revert to unstable-jumbo and just change that?
>> 
>> magnum
>> 
> 
> To me it is a mistery. I tried to copy "my code" and change variable names and it fails too.
> Why it works on some formats and not on others? No idea.
> I tried  CL_MEM_READ_ONLY / CL_MEM_READ_WRITE / etc. Nothing helped. At least, this makes sense.

Too bad, I couldn't help hoping we found it :(

> So, this cryptsha256 (and 512 and raw) code could start failing someday? Maybe.

Yes... or maybe it's something else I do that you don't (or vice versa), that gets randomly hidden by something else. I'm not 100% sure we should change the current code at all, as long as we don't find anything that violates spec.

In case the newest stable AMD drivers still fails when we are near next release, I could perhaps make non-mapping alternatives with "#ifdef AMD_WORKAROUND", have that default to unset and document it in doc/BUGS.

> Even crazier; commit a99312a works on Radeon 6770, GTX 570 and CPUs. Without doing the proper allocation? Yes. How? It shouldn't!!

You mean the host code gets a pointer that is not made with CL_MEM_ALLOC_HOST_PTR? This is not bound to fail, it's just not guaranteed to work... On most platforms I guess it will work fine, especially 64-bit ones.

magnum

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ