[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABob6iq8sgDyzVCtxNmbXwPBx-eAaY5xvutrrDMNf2SNyx6fpQ@mail.gmail.com>
Date: Tue, 14 May 2013 18:31:40 +0200
From: Lukas Odzioba <lukas.odzioba@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: des-opencl salt binaries
2013/5/14 Sayantan Datta <std2048@...il.com>:
> Hi Solar,Lukas,Daniel
>
> I had been playing around with des-opencl GCN binaries for the last few
> days. So,I built all the 4096 kernel binaries to see how much they differ
> among themselves.
Awesome.
> During the process I found the following:
>
> Opencl binaries generated with build option "-fno-bin-llvmir
> -fno-bin-source -fbin-exe -fno-bin-amdil" still contains the AMD IL ,
> however in a much different location.
>
> OpenCl binaries so generated have following sections:
> .rodata - very small in size and same for all kernel
> .text - this is the section of our main interest and it is an elf object
> itself.
> .comment - very small , not intersted.
>
> Now the offset and size of above .text section can be extracted using
> command 'objdump -h filename' and a custom script.
Could you please upload this script to wiki? It will help others.
> The main ISA(only the instructions) which is same for all 4096
> kernels is only 4168 bytes. The associated data(memory addresses and
> constant buffer address etc) is excess of 62KB and it is different for all
> 4096 kernels.
I am having trouble to imagine how this data is organized. Could you
post some samples for 2 different kernels?
62kB * 4096 = 254MB, we should try to achieve that somehow.
If I understood well, this is the data that really matters so instead
of compressing
4k kernels we can compress 1 kernel and 4k of that data and then "patch"
binary by big chunk of data in the runtime.
> Even though the data section is different for all kernels,
> chunks of bytes staring at different offsets were found to be same when
> compared to a base kernel. Nearly 40 to 70% of all data sections are same
> even though they have different offset locations in the kernel.
> However the difference between the data in the kernel is still too large to make
> runtime patching possible.
The question is, can fix something that compiler screwed to make
patching possible?
Lukas
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
