Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 19 Dec 2012 10:27:58 -0200
From: Claudio André <claudioandre.br@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Opencl build from binary

Em 18-12-2012 17:39, magnum escreveu:
> On 18 Dec, 2012, at 15:39 , Claudio André <claudioandre.br@...il.com> wrote:
>> 2012/7/5 SAYANTAN DATTA <std2048@...il.com>:
>>> I want to make a patch for JtR for building opencl programs from binaries.
>>> So should I make  a seperate file or should I modify the common-opencl.c ?
>>> If I am given the permission to modify the common-opencl.c, I will ensure
>>> that it doesn't create any problems for the current build.
> Is the intention to "cache" compiled kernels for later runs? Nvidida's drivers already do this, but not AMD from what I can tell.

Yes and yes. It is very useful on AMD compilation time on GPU. NVIDIA 
just ignores it.


>
>> Hi, i created a new patch using this. Unfortunately, i had to change common-opencl a little. Please check if the change is acceptable.
>> - it doesn't impact or hurt legacy code.
>> - if anyone want to use it, only code inside the format xxx_fmt.c file has to be created.
>> - everything seems fine, but more tests are needed. Specially on different platforms (i mean OSX).
> I just tried applying it and built under OSX with no problems, I see no problems with committing it.

I am worried about running the binary later. It is what all closed 
source software is doing now, but i had troubles in all "security" 
closed source software i tried here (i tried two).
Since we build using the target machine, i suppose it is not going to be 
a problem. But, who knows...

> From a quick look at opencl_cryptsha512_fmt.c in your repo, I wonder 
> why you didn't make more of it shared? The format could just call 
> opencl_build_kernel() and the common code could use the binary if 
> available, transparent to the format. However, I guess we need some 
> kind of version-control. Or is there already? I didn't look very 
> closely. It could be like

Of course more can be shared. And, in this case, version control is needed.

> if (no binary) OR (timestamp of source is newer than timestamp of binary)
> 	build [and write/overwrite binary]
> else
> 	use binary
>
> Or is that too simple? I can't think of any problems with that.

This plus different binary file names (according to device name) seems 
to be ok to me too.


>
>> BTW: should we move the .cl files to a new folder, e,g. "../run/kernels" and save binary files there? We have dozens of OpenCL files now.
> I had that idea too but then we'd need to ensure that system-wide builds doesn't break. And I'm too lazy to test that :-)

What do you mean by system-wide? cp john dir to /usr/bin and set PATH to 
it? Use packages from, for example, http://pkgs.org <http://pkgs.org/>?

Claudio


[ CONTENT OF TYPE text/html SKIPPED ]

Powered by blists - more mailing lists

Your e-mail address:

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