[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+EaD-ZJ=HckyM-Z4xbcZ-JYL7s4+2h3DCN6rF82BQNF4Fk-Aw@mail.gmail.com>
Date: Wed, 24 Jul 2013 19:18:23 +0200
From: Katja Malvoni <kmalvoni@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Katja's weekly report #6
Hi Alexander, Yaniv
On Wed, Jul 24, 2013 at 2:28 AM, Solar Designer <solar@...nwall.com> wrote:
> Hi Katja,
>
> On Mon, Jul 22, 2013 at 11:59:43PM +0200, Katja Malvoni wrote:
> > Accomplishments:
> > 1. Integration with JtR finished
>
> Cool. Just how confident are we that it's working reliably, though?
> Yes, the 2-hour run has succeeded, but if e.g. one in 10k hashes were
> not computed/transferred correctly then chances are that this would not
> be noticed in a run that is only supposed to get 3k passwords cracked.
>
> My concern is that, if I understood Yaniv correctly, the data transfers
> to/from Epiphany do not have to complete in-order, yet your code relies
> on the flags being seen strictly before/after the data.
>
That's true. But If I do some sort of check by host that the new data was
written and than set start flag, than it must be busy wait and that will
make it slower. Any other approach will have the same problem.
So I replaced for loop used to send data to cores with this:
core_start = 16;
for(i = 0; i < platform.rows*platform.cols; i++)
{
ERR(e_write(&emem, 0, 0, offsetof(data, setting[i]), &saved_salt,
sizeof(BF_salt)), "Writing salt to shared memory failed!\n");
while(test_salt.salt[0] != saved_salt.salt[0])
ERR(e_read(&emem, 0, 0, offsetof(data, setting[i]), &test_salt,
sizeof(BF_salt)), "Writing salt to shared memory failed!\n");
ERR(e_write(&emem, 0, 0, offsetof(data, init_key[i]),
&BF_init_key[i], sizeof(BF_key)), "Writing key to shared memory failed!\n");
while(test[0] != BF_init_key[i][0])
ERR(e_read(&emem, 0, 0, offsetof(data, init_key[i]), &test,
sizeof(BF_key)), "Checking key failed!\n");
ERR(e_write(&emem, 0, 0, offsetof(data, exp_key[i]),
&BF_exp_key[i], sizeof(BF_key)), "Writing key to shared memory failed!\n");
while(test[0] != BF_exp_key[i][0])
ERR(e_read(&emem, 0, 0, offsetof(data, exp_key[i]), &test,
sizeof(BF_key)), "Checking key failed!\n");
ERR(e_write(&emem, 0, 0, offsetof(data, start[i]), &core_start,
sizeof(core_start)), "Writing start failed!\n");
}
And now I'm getting 930 c/s. This should be safer because data is there
before writing start. But ideally, all array members should be tested, not
just the first one and that'll make it even slower.
For reading, I have to remember previous result to be able to check that
new result is different. But this would stuck in case that one core
computes same hash as in previous iteration (what is the probability of
this event?). If I don't do that, I'm again relying on handshaking and that
requires deterministic order of execution.
Yaniv, in Epiphany Architecture Reference 4.13.01.04, p. 20, Table 1 - is
this order guaranteed only for instructions executed by Epiphany cores? Are
reads and writes to/from core local memory executed by host also non
deterministic? On p.19 of same pdf: "To ensure that these effects do not
occur in code that requires strong ordering of load and store operations,
use run-time synchronization calls with order-dependent memory sequences."
- where can I find more about those calls? I wasn't able to find them in
SDK reference (at least not under that name).
> Maybe you can test similar data transfers in a dummy application that
> would do very little computation (so it'd spend most of its time on the
> transfers back and forth), but would instead deliberately try to detect
> cases of out-of-order arrival?
>
I started with this - created and tested only data transfers (hash, key,
start and done) without computation and than introducing variable delays
using timers. And in all runs I did, data transfers were correct. I was
checking data in same way I'm reading result now, again relying on having
data there before done flag is set.
I'll check it one more time, it won't take much time.
Katja
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.
