[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFYn=yAYcws+8VPY8D0g8TNsYCEENatFtW7iqx96UFauc1Eo+A@mail.gmail.com>
Date: Wed, 10 Jul 2013 15:00:24 -0400
From: Yaniv Sapir <yaniv@...pteva.com>
To: john-dev@...ts.openwall.com
Subject: Re: Parallella: bcrypt
Katja,
What system are you working on? Can I try to play with your code on your
machine (I have a login account, just let me know what machine it is and
where to find this code).
Thanks,
Yaniv.
On Wed, Jul 10, 2013 at 9:13 AM, Katja Malvoni <kmalvoni@...il.com> wrote:
> Hi Yainv,
>
> I moved my mailbox buffer from shared memory to core local memory. In JtR,
> when executing self test, in second iteration (for first one I get correct
> result) I get the following error:
> john: ee_write_esys(): /dev/mem file open failure.
>
> If I set verbosity to H_D1 and L_D1 I get this:
>
> e_set_loader_verbosity(): setting loader verbosity to 1.
> e_reset_system(): resetting full ESYS...
> john: ee_write_esys(): /dev/mem file open failure.
> e_reset_system(): done.
> e_load_group(): loading SREC file parallella_e_bcrypt.srec ...
> ee_process_SREC(): loading core (0,0).
> ...
> ee_process_SREC(): loading core (3,3).
> e_load_group(): done loading.
> e_load_group(): closed connection.
> e_load_group(): leaving loader.
> e_start(): SYNC (0xf042c) to core (0,0)...
> e_start(): done.
> ...
> e_start(): SYNC (0xf042c) to core (3,3)...
> e_start(): done.
>
> If I use H_D2 and L_D2 I get
> ...
> e_init(): platform.(row,col) = (32,8)
> e_init(): platform.(rows,cols) = (4,4)
> e_reset_system(): resetting full ESYS...
> john: ee_write_esys(): /dev/mem file open failure.
> e_reset_system(): found chip version E16G301, programming clock divider.
> ee_get_id_from_coords(): dev.row=34, dev.col=11, row=0, col=0, CoreID=0x88b
> e_open(): group.(row,col),id = (34,11),0x88b
> e_open(): group.(rows,cols),numcores = (1,1), 1
> e_open(): opening core (0,0)
> ...
>
> It seems that e_reset_system() fails -
> https://github.com/adapteva/epiphany-libs/blob/master/src/e-hal/src/epiphany-hal.cline 840, should there be a check of return value?
>
> Katja
>
>
> On Tue, Jul 9, 2013 at 6:43 PM, Katja Malvoni <kmalvoni@...il.com> wrote:
>
>>
>> On Tue, Jul 9, 2013 at 4:45 AM, Yaniv Sapir <yaniv@...pteva.com> wrote:
>>
>>>
>>> I tried this and for me it doesn't work, I don't get correct results.
>>>> I took code I sent you (
>>>> http://www.openwall.com/lists/john-dev/2013/07/06/3) and did only
>>>> that, commented out "outbuf.start[corenum] = 0" and some cores return wrong
>>>> results. Even worse, cores that return wrong results are different for
>>>> every run and wrong results are also different. Output that I get is
>>>> attached. Could you please check that you changed only that?
>>>>
>>>>
>>> Sorry if it was not clear, but in addition to commenting out the
>>> "start[]" signal, I also added a dummy place-holder after the "done" member
>>> of the structure, to make sure both sides have the same member alignment.
>>>
>>> I did the same and I still get wrong results. I also changed BufSize to
>> 0x1000 but it didn't help. Again, some data is not transferred correctly:
>>
>>
>> eCore 0x808 (0, 0): 1bb69143, f9a8d304, c8d23d99, ab049a77, a68e2ccc,
>> 74420600
>> eCore 0x809 (0, 1): 0, 0, 0, 0, 0, 0
>> eCore 0x80a (0, 2): 6f15130a, 8d681e90, 5cfec901, f4493e64, ebb352f8,
>> 35ce3600
>> eCore 0x80b (0, 3): 2bfd15b2, 71622fde, b982676d, 22550521, 45957d0e,
>> 1ae35200
>>
>> eCore 0x848 (1, 0): 1bb69143, f9a8d304, c8d23d99, ab049a77, a68e2ccc,
>> 74420600
>> eCore 0x849 (1, 1): 1bb69143, f9a8d304, c8d23d99, ab049a77, a68e2ccc,
>> 74420600
>> eCore 0x84a (1, 2): 1bb69143, f9a8d304, c8d23d99, ab049a77, a68e2ccc,
>> 74420600
>> eCore 0x84b (1, 3): 1bb69143, f9a8d304, c8d23d99, ab049a77, a68e2ccc,
>> 74420600
>> eCore 0x888 (2, 0): 1bb69143, f9a8d304, c8d23d99, ab049a77, a68e2ccc,
>> 74420600
>> eCore 0x889 (2, 1): 1bb69143, f9a8d304, c8d23d99, ab049a77, a68e2ccc,
>> 74420600
>> eCore 0x88a (2, 2): 1bb69143, f9a8d304, c8d23d99, ab049a77, a68e2ccc,
>> 74420600
>> eCore 0x88b (2, 3): 1bb69143, f9a8d304, c8d23d99, ab049a77, a68e2ccc,
>> 74420600
>> eCore 0x8c8 (3, 0): 1bb69143, f9a8d304, c8d23d99, ab049a77, a68e2ccc,
>> 74420600
>> eCore 0x8c9 (3, 1): 1bb69143, f9a8d304, c8d23d99, ab049a77, a68e2ccc,
>> 74420600
>> eCore 0x8ca (3, 2): 1bb69143, f9a8d304, c8d23d99, ab049a77, a68e2ccc,
>> 74420600
>> eCore 0x8cb (3, 3): 1bb69143, f9a8d304, c8d23d99, ab049a77, a68e2ccc,
>> 74420600
>> Execution time - Epiphany: 19.926000 ms
>> done = 16
>>
>> core_done[ 0] = 1 test[ 0] = 16 ciphertext[0] = P
>> core_done[ 1] = 1 test[ 1] = 16 ciphertext[1] = P
>> core_done[ 2] = 1 test[ 2] = 16 ciphertext[2] = P
>> core_done[ 3] = 1 test[ 3] = 16 ciphertext[3] = P
>> core_done[ 4] = 1 test[ 4] = 16 ciphertext[4] = P
>> core_done[ 5] = 1 test[ 5] = 16 ciphertext[5] = P
>> core_done[ 6] = 1 test[ 6] = 16 ciphertext[6] = P
>> core_done[ 7] = 1 test[ 7] = 16 ciphertext[7] = P
>> core_done[ 8] = 1 test[ 8] = 16 ciphertext[8] =
>> core_done[ 9] = 1 test[ 9] = 16 ciphertext[9] = P
>> core_done[10] = 1 test[10] = 16 ciphertext[10] = P
>> core_done[11] = 1 test[11] = 16 ciphertext[11] = P
>> core_done[12] = 1 test[12] = 16 ciphertext[12] = P
>> core_done[13] = 1 test[13] = 16 ciphertext[13] = P
>> core_done[14] = 1 test[14] = 16 ciphertext[14] =
>> core_done[15] = 1 test[15] = 16 ciphertext[15] =
>> ciphertext = P
>>
>> If I pass e_false as parameter to e_load_group() and than start cores
>> with e_start(), than it works. I guess that when I pass e_true as argument
>> to e_load_group(), cores start bcrypt computation but not all data is
>> transferred and that is why some cores return incorrect results. Normally I
>> would use e_start() to start cores because it works but there are problems
>> with JtR integration.
>> When cracking passwords, after 60 to 65 passwords are cracked I get
>> following error: john: e_alloc(): mmap failure
>> I set verbosity for host and loader to H_D4 and L_D4 (this was overhead,
>> probably H_D1 and L_D1 would be enough) and this happens while allocating
>> memory for loading *.srec file. Can this be a consequence of calling
>> e_init(), e_reset_system(), e_open(), e_alloc(), e_load_group(), e_close(),
>> e_free() and e_finalize() every time Epiphany chip is used?
>>
>> Katja
>>
>
>
>
> --
> Katja
>
--
===========================================================
Yaniv Sapir
Adapteva Inc.
1666 Massachusetts Ave, Suite 14
Lexington, MA 02420
Phone: (781)-328-0513 (x104)
Email: yaniv@...pteva.com
Web: www.adapteva.com
============================================================
CONFIDENTIALITY NOTICE: This e-mail may contain information
that is confidential and proprietary to Adapteva, and Adapteva hereby
designates the information in this e-mail as confidential. The information
is
intended only for the use of the individual or entity named above. If you
are
not the intended recipient, you are hereby notified that any disclosure,
copying,
distribution or use of any of the information contained in this
transmission is
strictly prohibited and that you should immediately destroy this e-mail and
its
contents and notify Adapteva.
==============================================================
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.
