[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 14 May 2013 21:16:13 +0530
From: Sayantan Datta <std2048@...il.com>
To: john-dev@...ts.openwall.com
Subject: des-opencl salt binaries
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. 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. So I extract the .text
section into a new file. Now the new file has following sections(using
command '*objdump -h newfile*'):
.text - This section contains the AMD IL again. Its size is very large and
occupies nearly 85% of the full openCL object. So, I zeroed this section
section entirely.Fortunately zeroing the IL didn't affect the runtime
characteristics of binary. This enabled huge amount
compression since the AMD-IL portion is very different for different
different des salts.
.data - contains 1280 bytes of zeroes padding.
.text - This section contains the actual ISA and the associated memory
addresses. If we see the ISA for different salts , all of them are exactly
same. This puzzled me in the beginning but the ISA is only the tip of the
ice berg.
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.
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. I instead focused on improving compression
rather than runtime patching. So I zeroed big chunks
which were similar to the base kernel and stored the necessary
offsets in a file.
.data - again 1280 bytes of zero padding .
Finally I merged all 4096 kernels to a single file which improves
compression a little bit. Now the compressed recoverable binaries have size
7.7MB using 7z , 52MB using rar and 61MB using tar. I can automate the
extraction and patching process, but the final extracted kernels would take
around 1.5GB disk space.
Regards,
Sayantan
Content of type "text/html" skipped
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.
