Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 23 Apr 2015 18:25:27 +0800
From: Lei Zhang <zhanglei.april@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: [GSoC] JtR SIMD support enhancements


> On Mar 29, 2015, at 5:38 AM, Solar Designer <solar@...nwall.com> wrote:
> 
> There is.  We currently only have MIC intrinsics introduced for DES.
> You should introduce them for whatever other formats currently have
> intrinsics for SSE2 and such.  magnum already told you where to start,
> but he spoke in context of AVX2 and AVX-512.  Well, for AVX-512 you'd
> start with MIC intrinsics, which are mostly the same.

I just finished adding MIC/AVX512 support to the remaining formats in JtR (great thanks to magnum's work). Now all formats with MIC intrinsics enabled passed self-tests on MIC. I'm having some trouble building JtR with AVX512 enabled, thus haven't tested it on Intel SDE yet.

> Another potential sub-task for MIC is to add OpenMP offload support.
> Right now, we're only building for MIC fully natively.  This runs fast,
> but in typical installs it means that JtR's input and output files
> reside in the MIC card's RAM, and will be lost if the card is rebooted.
> (This may be corrected by mounting a host directory via NFS.)  Also, to
> use multiple MIC cards, multiple instances of JtR need to be managed
> manually (or with scripts), whereas with OpenMP offload this might be
> transparent to the user.

I just started doing this and encountered a couple of issues. Below are the files I played with and the corresponding issues.

BF_std:
Currently this is the only one that works.
-----------------------------------------------------
[zhanglei@...ter src]$ ../run/john --test --format=bcrypt
Will run 12 OpenMP threads
Benchmarking: bcrypt ("$2a$05", 32 iterations) [Blowfish 32/64 X2]... DONE
Raw:    1552 c/s real, 1555 c/s virtual
-----------------------------------------------------

MD5_std:
The program get's a segmentation fault in the offloaded code part.
-----------------------------------------------------
[zhanglei@...ter src]$ ../run/john --test --format=md5crypt
Will run 12 OpenMP threads
offload error: process on the device 0 was terminated by signal 11 (SIGSEGV)
-----------------------------------------------------

DES_bs_b:
This error message is kind of cryptic...
-----------------------------------------------------
[zhanglei@...ter src]$ ../run/john --test --format=descrypt
Will run 12 OpenMP threads
offload error: cannot find offload entry __offload_entry_DES_bs_b_c_1384DES_bs_crypt_25icc671353031cen64y
offload error: process on the device 0 unexpectedly exited with code 1
-----------------------------------------------------

c3_fmt:
Got a link error when building:
-----------------------------------------------------
c3_fmtMIC.o: In function `crypt_all':
c3_fmt.c:(.text+0x310): undefined reference to `crypt_r'
c3_fmt.c:(.text+0x332): undefined reference to `crypt_r'
-----------------------------------------------------
This error is really strange. I wrote a simple program that uses crypt_r and tested it on MIC. It works well on native mode, but won't compile on offload mode, with the similar error message as above.


So far the biggest trouble adding offload support is handle use of pointers. The offload directive can only auto-transfer bitwise-copyable variables. Those dynamic-allocated objects used in offloaded code must be handled manually and very carefully. I guess it's the culprit for some of the errors above. I'll need to investigate it further.

Yet I found another minor issue. There're some highly-optimized functions defined in nonstd.c, named s1, s2, etc. Most of them have several implementations, and the preprocessor chooses the best implementation depending on the underlying CPU. When compiling on offload mode, the best implementation for the host CPU is not necessary best for MIC. This won't affect correctness, though.


Lei


[ CONTENT OF TYPE text/html SKIPPED ]

Powered by blists - more mailing lists

Your e-mail address:

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