Yuri's Status Report - #12 of 15

[Yuri Gonzaga]

Hello,

I started to integrate JtR with one core using the patched provided.
However, I can't get sucess in compiling all together.
It was possible to generate *.o files from $(PICOBASE)/software/source.
But, calls to JtR's Makefile are getting a lot of strange errors I couldn't
overcome until now.
Maybe, the mixture of JtR's C code with Pico's C++ one is causing this
problem in compilation.
A log file is attached as a way to help me to fix this issue.

I finished the verilog code of manager to use several cores in FPGA, but I
can't test in the board once I am stuck on that compilation problem.

I will be very grateful if you could help me with this errors.

Thanks!

Yuri

[Solar Designer]

Yuri, David -

Post by Yuri Gonzaga
I started to integrate JtR with one core using the patched provided.
However, I can't get sucess in compiling all together.
It was possible to generate *.o files from $(PICOBASE)/software/source.
But, calls to JtR's Makefile are getting a lot of strange errors I couldn't
overcome until now.
Maybe, the mixture of JtR's C code with Pico's C++ one is causing this
problem in compilation.
A log file is attached as a way to help me to fix this issue.

Unfortunately, it is nearly impossible to help you without seeing the
corresponding source code changes as well. Can you please post a
"patch" showing your changes to BF_std.c (generate it with "diff -u")?

Per David's comment from a week ago, are you sure you're including
header files for the API rather than those for the drivers?

David - may I have access to the server that Yuri is developing on?

It is a pity that the multi-core support won't be ready/usable for
KoreLogic's "Crack Me If You Can" contest at DEFCON starting in just two
days from now:

http://www.openwall.com/lists/announce/2011/08/02/1

As to the main focus of our project, originally defined as password
hashing for servers, I think we need to build such a password hashing
method on top of Eksblowfish cores in FPGA initially - for proof of
concept, to have a baseline, and to experiment with the interfaces. So
we will be doing multiple instances of Eksblowfish running in parallel
even as part of a single password hash computation. I still do think
that we'll need to move to something using the FPGA more optimally, but
we may do it at a later time - beyond GSoC. At this point, it is
unrealistic that we'll be able to complete this move in August, so it
makes more sense to build upon Yuri's existing work on Eksblowfish.

Thanks,

Alexander

[Yuri Gonzaga]

Post by Solar Designer
Unfortunately, it is nearly impossible to help you without seeing the
corresponding source code changes as well. Can you please post a
"patch" showing your changes to BF_std.c (generate it with "diff -u")?

I was going to generate a patch to share with you, but it seems that the
password to access my account on picocomputing.com has changed.
David, do you confirm that?

Per David's comment from a week ago, are you sure you're including

Post by Solar Designer
header files for the API rather than those for the drivers?

Yes, I am sure.

David - may I have access to the server that Yuri is developing on?


Althought, it isn't working by now, I can tell you details to connect to my
account.

It is a pity that the multi-core support won't be ready/usable for

Post by Solar Designer
KoreLogic's "Crack Me If You Can" contest at DEFCON starting in just two
days from now

Oh, I am really sorry for that.
If I knew before, maybe I could have used more effort for this purpose.

As to the main focus of our project, originally defined as password

Post by Solar Designer
hashing for servers, I think we need to build such a password hashing
method on top of Eksblowfish cores in FPGA initially - for proof of
concept, to have a baseline, and to experiment with the interfaces. So
we will be doing multiple instances of Eksblowfish running in parallel
even as part of a single password hash computation. I still do think
that we'll need to move to something using the FPGA more optimally, but
we may do it at a later time - beyond GSoC. At this point, it is
unrealistic that we'll be able to complete this move in August, so it
makes more sense to build upon Yuri's existing work on Eksblowfish.

Agreed.

Thank you,

---
Yuri

[Solar Designer]

Yuri, David -

Now that David restored our access to the machine (thanks!), I got
Yuri's modified John the Ripper tree to build.

Post by Yuri Gonzaga
I started to integrate JtR with one core using the patched provided.
However, I can't get sucess in compiling all together.
It was possible to generate *.o files from $(PICOBASE)/software/source.
But, calls to JtR's Makefile are getting a lot of strange errors I couldn't
overcome until now.
Maybe, the mixture of JtR's C code with Pico's C++ one is causing this
problem in compilation.

Yes, this was one of the primary problems. Not so much the fact that
Pico's *.o's were compiled from C++ files, but primarily the fact that
Pico's header files were also C++'ish. Anyway, I managed to mix them
such that the thing builds. Please see john-s-1.diff and john-s-2.diff
in your home directory to find out what changes I made in the john-s
tree relative to your john tree.

Now it fails at runtime when actually trying to communicate to the FPGA:

***@optiplex980:~/john-s/src$ ../run/john -te -fo=bf
Benchmarking: OpenBSD Blowfish (x32) [32/64 X2]... Error Writing: -1

Yuri - it's your turn. I guess you need to actually load the bitstream
into the FPGA somewhere/somehow. Do you know how to do that on this
machine? Did you successfully access the FPGA with the sample programs?

Please let us know.

Thanks,

Alexander

[Yuri Gonzaga]

Post by Solar Designer
Benchmarking: OpenBSD Blowfish (x32) [32/64 X2]... Error Writing: -1
Yuri - it's your turn. I guess you need to actually load the bitstream
into the FPGA somewhere/somehow. Do you know how to do that on this
machine? Did you successfully access the FPGA with the sample programs?

I was not loading the bitstream directly in the code. I was doind it before
using another tool.
But it's easy to include it in the code.
It already worked in sample programs.

So, I will take a look in your diff's and back to report the status ASAP.

Thank you very much.

Yuri

[Solar Designer]

Yuri -

Post by Yuri Gonzaga
I was not loading the bitstream directly in the code. I was doind it before
using another tool.
But it's easy to include it in the code.
It already worked in sample programs.

For now, I am fine with you doing it either way. Just make it work and
show how you do it - such that I can try it out too. I don't mind
running two shell commands instead of one.

Post by Yuri Gonzaga
So, I will take a look in your diff's and back to report the status ASAP.

Yes, please do.

Thanks,

Alexander

[Yuri Gonzaga]

Post by Solar Designer
For now, I am fine with you doing it either way. Just make it work and
show how you do it - such that I can try it out too. I don't mind
running two shell commands instead of one.

I included in the code, but I can't test by now for the reason below.

Post by Solar Designer

Post by Yuri Gonzaga
So, I will take a look in your diff's and back to report the status ASAP.

Yes, please do.

The same problem reported in [1] is still happening.
Even if I try to compile the helloworld without any change, it happens.

So, I can't generate the bitstream and consequently run the JtR.

David, Could you help me please?

[1] http://www.openwall.com/lists/crypt-dev/2011/08/09/1

Regards,

Yuri

-----------------------
Full list of errors:

ERROR:PhysDesignRules:2399 - The GTXE1 comp
PicoFramework/core/pcie_2_0_i/pcie_gt_i/gtx_v6_i/GTXD[0].GTX has
POWER_SAVE[4] set to an unsupported value and must be set to 1. Please
see Answer Record 39430 for more information.
ERROR:PhysDesignRules:2399 - The GTXE1 comp
PicoFramework/core/pcie_2_0_i/pcie_gt_i/gtx_v6_i/GTXD[1].GTX has
POWER_SAVE[4] set to an unsupported value and must be set to 1. Please
see Answer Record 39430 for more information.
ERROR:PhysDesignRules:2399 - The GTXE1 comp
PicoFramework/core/pcie_2_0_i/pcie_gt_i/gtx_v6_i/GTXD[2].GTX has
POWER_SAVE[4] set to an unsupported value and must be set to 1. Please
see Answer Record 39430 for more information.
ERROR:PhysDesignRules:2399 - The GTXE1 comp
PicoFramework/core/pcie_2_0_i/pcie_gt_i/gtx_v6_i/GTXD[3].GTX has
POWER_SAVE[4] set to an unsupported value and must be set to 1. Please
see Answer Record 39430 for more information.
ERROR:PhysDesignRules:2399 - The GTXE1 comp
PicoFramework/core/pcie_2_0_i/pcie_gt_i/gtx_v6_i/GTXD[4].GTX has
POWER_SAVE[4] set to an unsupported value and must be set to 1. Please
see Answer Record 39430 for more information.
ERROR:PhysDesignRules:2399 - The GTXE1 comp
PicoFramework/core/pcie_2_0_i/pcie_gt_i/gtx_v6_i/GTXD[5].GTX has
POWER_SAVE[4] set to an unsupported value and must be set to 1. Please
see Answer Record 39430 for more information.
ERROR:PhysDesignRules:2399 - The GTXE1 comp
PicoFramework/core/pcie_2_0_i/pcie_gt_i/gtx_v6_i/GTXD[6].GTX has
POWER_SAVE[4] set to an unsupported value and must be set to 1. Please
see Answer Record 39430 for more information.
ERROR:PhysDesignRules:2399 - The GTXE1 comp
PicoFramework/core/pcie_2_0_i/pcie_gt_i/gtx_v6_i/GTXD[7].GTX has
POWER_SAVE[4] set to an unsupported value and must be set to 1. Please
see Answer Record 39430 for more information.
ERROR:Pack:1642 - Errors in physical DRC.

[Solar Designer]

David - please help answer Yuri's question below ASAP.

Yuri -

Post by Yuri Gonzaga
The same problem reported in [1] is still happening.
Even if I try to compile the helloworld without any change, it happens.
So, I can't generate the bitstream and consequently run the JtR.
David, Could you help me please?
[1] http://www.openwall.com/lists/crypt-dev/2011/08/09/1

Oh, I was under impression that this problem only occurred when you
tried to synthesize multiple cores, so you could proceed with one core
until we hear from David. But now you say that even helloworld fails.

Post by Yuri Gonzaga
ERROR:PhysDesignRules:2399 - The GTXE1 comp
PicoFramework/core/pcie_2_0_i/pcie_gt_i/gtx_v6_i/GTXD[0].GTX has
POWER_SAVE[4] set to an unsupported value and must be set to 1. Please
see Answer Record 39430 for more information.

Have you tried looking into this yourself at all?

Thanks,

Alexander

[Yuri Gonzaga]

Post by Solar Designer
Have you tried looking into this yourself at all?

I found some articles related to this issue, as
http://www.xilinx.com/support/answers/39430.htm and
http://www.xilinx.com/support/answers/39456.htm
But I tried putting it into practice and I was not successful.
For example, I tried to change each file "gtx_wrapper_v6.v" found with
command "locate".
Each one has a line as ".POWER_SAVE(10'bxxxx10xxxx), " where I can force
POWER_SAVE[5:4] to "11" as suggested by the error message.
I did it, but it didn't solved the error.

Regards,

Yuri