Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 9 Dec 2012 05:23:26 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: bitslice DES on GPU

On Thu, Dec 06, 2012 at 11:32:41PM +0200, Milen Rangelov wrote:
> Why do you want to patch your kernels?

Primarily to reduce the register pressure, but also likely reduce the
number of instructions.  Like I mentioned, on CPU this makes for a 7%
speed difference (not currently implemented in JtR, I did not care
enough - although I did measure this).  On GPU, according to a test
Sayantan ran (hard-coding the values for a specific salt), "performance
increased from 67M to 110M" - and this speedup matches my expectation.

> I used to patch the kernel binaries for BFI (before AMD mapped it to
[...]
> that we have the ELF-inside-ELF situation. Once I understood that, I was
> finally able to find out where the binary code starts so that I could
> reliably patch the opcode.

Thank you for describing this!  I think you could do it differently
(maybe simpler): build two variations of the kernel, either with
different suitable placeholder instructions in place of BFI or with
different operands.  Then diff the two to find just the right places.
No need to parse ELF headers, then.

> Note that this is a rather simple case, for more advanced binary patching,
> this would become much more complex.

Right.

> I've seen in the AMD forums some
> people posting stuff about IL patching inside kernel. I don't really know
> how that works. Perhaps they compile from source, patch the IL section
> inside binary, strip the text section, then again pass that to
> clBuildProgram to get the final binary, but I am not quite sure about this.

We actually prefer to patch at ISA level, I think - so it'd be more
similar to what you were doing - except that we need to patch immediate
offset fields rather than opcodes.

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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