Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 27 Jul 2015 03:03:34 +0300
From: Aleksey Cherepanov <lyosha@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Re: ztex 1.15y boards, pre-development

On Mon, Jul 27, 2015 at 02:54:14AM +0300, Aleksey Cherepanov wrote:
> On Sun, Jul 26, 2015 at 11:58:47PM +0300, Aleksey Cherepanov wrote:
> > On Sun, Jul 26, 2015 at 08:51:42PM +0200, Katja Malvoni wrote:
> > > On 26 July 2015 at 20:12, Aleksey Cherepanov <lyosha@...nwall.com> wrote:
> > > >
> > > > But for me, it segfaulted first several runs and then it fails on every
> > > > run:
> > > >
> > > > S[0][0] = 0xd1310ba6 0xd131f12c <<< failure
> > > > S[0][1] = 0x98dfb5ac 0x98dfb5ac ok
> > > > S[0][2] = 0x2ffd72db 0x2ffd72db ok
> > > > S[0][3] = 0xd01adfb7 0xd01adfb7 ok
> > > > S[0][4] = 0xb8e1afed 0xb8e1afed ok
> > > > S[0][5] = 0x6a267e96 0x6a267e96 ok
> > > > S[0][6] = 0xba7c9045 0xba7c9045 ok
> > > > S[0][7] = 0xf12c7f99 0xf12c7f99 ok
> > > >
> > > 
> > > Hm... this looks like first word written by FPGA is the last one from the
> > > previous read/write cycle (0xf12c). And it's not the same problem as I get
> > > on my board :(
> 
> It seems I solved this problem: s/512/1024/ for reading
>  	// read string back from ucecho device 
> -	i = usb_bulk_read(handle, 2, (char *)(received), 512, 1000);
> +	i = usb_bulk_read(handle, 2, (char *)(received), 1024, 1000);
> 
> I guess you need a buffer of respective size, not just 8 uints.
> 
> -	unsigned int received[8] = {0};
> +	unsigned int received[0x100] = {0};
> 
> 1024 is quite strange for me: we need 8*4 bytes of data, why do we
> need to read 1024 bytes to get them?

Actually it reads 34 bytes back. I can't reproduce relation between
512 vs 1024 and good vs bad behaviour.

> BTW if I upload bitstream before firmware, I get
> Error sending data: No error
> 
> > I think I can reproduce your problem too: I changed integers
> > 
> >         sent[2] += 9;
> > 
> > I tried various timings, including pause between write and read: it
> > takes 5 runs to get new value back. (It does not affect the first
> > word.)
> > 
> > So first 4 runs of 5 give:
> > 
> > S[0][0] = 0xd1310ba6 0xd131f12c <<< failure
> > S[0][1] = 0x98dfb5ac 0x98dfb5ac ok
> > S[0][2] = 0x2ffd72e3 0x2ffd72e4 <<< failure
> > S[0][3] = 0xd01adfb7 0xd01adfb7 ok
> > [...]
> > 
> > then there is only the first failure.
> 
> 4 runs lag remains.

I think, I got how to bypass it: read 5 times and skip results from
first 4 times. Also there is a difference: with wrong data I got 32
bytes back, while good data come in 34 bytes "packet".

I tried up to 20 reads, only fifth seem to be right.

Thanks!

-- 
Regards,
Aleksey Cherepanov

Powered by blists - more mailing lists

Your e-mail address:

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