hashkill - testing bitcoin miner plugin

[smgoller]

Just tested this with two 5870s. Hashkill gave me roughly 640Mh/s, whereas running two instances of phoenix got me 760Mh/s (2x380Mh/s)....

[gat3way]

I can test this with 5970s but I don't like the idea of installing things into /usr/share or requiring root privs for anything. Can I configure to pull the kernels from /home/user/share or the like?

Users for the hash cracking part requested that on a number of occasions. The reason I am not reluctant to do this is that it creates a possible security problem. The architecture consists of a core binary (hashkill-gpu) and a number of plugins that are in fact shared libraries  (/usr/share/hashkill/plugins) and are loaded dynamically. Having the libraries located in a path that is only writable by root ensures noone can play nasty tricks. If I let the users install them wherever they want, someone might install them in a world-writable directory. This creates a security hole because anyone that can overwrite files there, can take advantage of that to mount local privilege escalation attacks. Besides (from the hash cracking perspective) I don't feel comfortable with the idea that anyone can install the program to crack hashes, without superuser knowledge. So - if you are the owner of the machine - you will install that anyway. If you are an ordinary user and you really need that, you can ask the admin to install it. I am not letting users to crack hashes on a system they don't have permission to. It is resource-intensive process and it may be related to illicit activities.

[marcus_of_augustus]

I'm not going to install any binaries with root privileges without seeing the source.

Particularly not one from a hash-cracking expert, that would be a huge security hole, wouldn't you agree? Would you do it?

[netxshare]

I'm not going to install any binaries with root privileges without seeing the source.

Particularly not one from a hash-cracking expert, that would be a huge security hole, wouldn't you agree? Would you do it?

I can understand this, I have worked with gat3way on testing this over IRC on my 6990 system and 5970 I have also seen the source code. You can also get code for everything but the bitcoin plugin off his website. But I am sure when he is ready he will release the code to the public.

[gat3way]

Root privileges are needed only for the installation and the installer script is apparently open source. Then yes - it's a question whether you trust binaries and it is a valid point. Then again, you already do that as the whole OpenCL stack is proprietary. So at the end it boils down to whom you trust to provide you binaries. Of course, in theory I could trojanize you, I could put your system in an evil botnet whose aim is to (say hm) generate bitcoins for me. Not that this wouldn't show up in a simple strace output for example, but then not anyone would bother to check that. Well, it's obvious I can't give you guarantees on that and it's all a matter of trust. Of course, I can make claims as much as I want, but apparently it does not matter.

Until I can get it to a point where I consider it stable enough, I am not putting the code in public. That is my personal choice and I have the right to do that just as you have the right to build some conspiracy theory around that. Source is available upon request though and I would not refuse to provide this to anyone that tests it. However, I am not willing to release it in public at that moment. It will be released soon, but only after I eliminate the present issues and integrate the functionality I've planned.

[marcus_of_augustus]

No conspiracy theory, I think you are probably doing some good work here, it has the right pedigree.

Just it would be bad practice to do what you are asking for people who are testing it ... unless of course they know and can trust you. I'm pretty sure you wouldn't do it yourself, knowing which side of the security fence you come from. Good luck, carry on.

"Here I've got a binary that is a sub-system for your digital currency miner, just use root to install it and you'll be sweet." (Has a bad look, if you know what I mean.)

[Dusty]

Root privileges are needed only for the installation

I think that a non-root user could create a chroot system to install and use it anyway, so I suppose this is not a valid concern.

[gat3way]

I am not a firm believer in the theory that opensourcing something would automatically eliminate chances of having deliberately planted malicious code. Its the peer review that eliminate that, not the public source itself (see the underhanded C contest eheh).

Yes, source is the prerequisite, however there is also something else. Hashkill has already turned into a relatively large enough project (~130-140.000 lines of code at present) with a good number of dependencies and supporting all this in my spare time is not easy. I add new functionality faster than I fix bugs (unfortunately as my spare time is limited). This of course reflects on my autoconf/automake stuff (the bitcoin part brought 3 new dependencies - curl, json-c and ADL). Autoconf macros are still buggy and building is a bitch. There are also sometimes some minor API changes in some library that may fail everything. It's just not tested well enough at the moment. I don't feel like answering questions like "build failure XXX, please help" while having to fix some serious issues with the bitcoin code. Static-linked binaries are a nice way to make it working for most distros out there without depending on additional packages and stuff.

One might argue that rewriting everything in a higher-level language like e.g python would be a better idea and I completely agree. It is also much more portable. However it is already too late for this.

[marcus_of_augustus]

I am not a firm believer in the theory that opensourcing something would automatically eliminate chances of having deliberately planted malicious code. Its the peer review that eliminate that, not the public source itself (see the underhanded C contest eheh).

Yes, source is the prerequisite, however there is also something else. Hashkill has already turned into a relatively large enough project (~130-140.000 lines of code at present) with a good number of dependencies and supporting all this in my spare time is not easy. I add new functionality faster than I fix bugs (unfortunately as my spare time is limited). This of course reflects on my autoconf/automake stuff (the bitcoin part brought 3 new dependencies - curl, json-c and ADL). Autoconf macros are still buggy and building is a bitch. There are also sometimes some minor API changes in some library that may fail everything. It's just not tested well enough at the moment. I don't feel like answering questions like "build failure XXX, please help" while having to fix some serious issues with the bitcoin code. Static-linked binaries are a nice way to make it working for most distros out there without depending on additional packages and stuff.

One might argue that rewriting everything in a higher-level language like e.g python would be a better idea and I completely agree. It is also much more portable. However it is already too late for this.

Okay I can appreciate an argument like this ... if you tearing through a development stage things are flying everywhere and its easier to spit out binaries ... good on ya, poclbm and phoenix are tough competition.

In this case, it is probably best for people who want to test with this code to do it on a dedicated test rig or VM maybe, but not a production mining rig of a cluster or one with a real currency at stake or in the environment anyway.

[gat3way]

OK, newer (hopefully last) alpha is ready.

New in that release:

* Fixed the "fflush" problem: now progress is displayed correctly, not updated with a newline
* Better getwork mechanism: smaller granularity for queueing thread, separate "submit" threads meaning that network-related performance loss is reduced
* Fixed long polling - it is now working correctly and the stales number should greatly be reduced on pools that support it. Stales are still possible though cause the current kernel invocation is not being canceled. Chances are about 1/1000. Also, stales are possible due to HTTP latency issues.
* Added thermal statistics: at any time during mining, press ENTER key to get your GPU temperature and utilization stats
* Added thermal throttling: when a GPU reaches a certain temperature limit, it is being disabled for one minute. The temperature threshold is 90 degrees Celsius by default and can be changed via the -T command-line option
* Changed the kernel to use a worksize of 64. It does not reflect on performance but makes speed more "stable"
* Changed the VLIW4 kernel (69xx cards). Now it should be a bit slower, but more stable.

Not added:

* The failover protocol
* HTTP keep-alive
* HTTPS support

Note: Thermal throttling/monitoring work on ATI cards only at the moment. There are corner cases where it would not work (e.g having adapters not supported by OpenCL).


Download:

64-bit:
http://www.gat3way.eu/poc/hashkill-0.2.4-x86_64.tgz

32-bit:
http://www.gat3way.eu/poc/hashkill-0.2.4-x86.tgz


Reminder: use SDK 2.3 or newer!

[Jaime Frontero]

thank you, gat3way.

i'll install tonight and let you know.

[bolapara]

The whole 'root install' thing really doesn't matter.  Look at the install.sh script.  It's using root privs to copy files into /usr/bin and /usr/share/hashkill.  None of those files are setuid/gid.  When you actually execute the files, you are executing them (unless you are being silly and running hashkill as root or with sudo) with an unprivileged user account.  At that point, your risks are the same as if you ran a binary from your home directory.

Now, open code is a different story....

[gat3way]

OK to anyone that needs the source, here it is:

http://www.gat3way.eu/poc/hashkill-src.tgz

Well, at that point I am _not_ providing any support to anyone that has problems building it. Also, I cannot promise that at that point I am going to follow any suggestions, even if they sound very sensible. You'd need to set two environment vairables, ATISTREAMSDKROOT and ADLROOT set to proper paths in order to properly build that.

[Jaime Frontero]

per my previous post:

running a Sapphire 5770 @ 960 GPUcore, 250 Mem, a bit overvolted.  temp at a pretty constant 64 C.  Catalyst 11.3, SDK 2.4.  on debian testing with the 2.6.32-5-amd64 kernel.

i'm now running the latest version (still called 0.2.4-x86_64) on slush's pool.  173 Mhash/sec like a heartbeat.  efficiency at or above 100%.

a winner!

[Jaime Frontero]

been running non-stop on slush since my last post.  no real issues.

efficiency is down a touch - steady at 98-99%.

the 'stale' counter is session-additive, right?  it's up to 139.

Mhash/sec holding rock-solid at 173.  no variance at all.

if you'd like any generated logs or anything, let me know, gat3way.

 

[gat3way]

Efficiency can go over 100% or below 100% - it's a matter of luck. I've had some periods where it is way over 100%, also periods where it drops at 70-80%. Overall with time it should get close to 100% though. The stale counter is additive, yes.

BTW could you provide me the ISA dump?

I am mostly interested in the SQ_PGM_RESOURCES:NUM_GPRS field which should be among the last lines.

[Jaime Frontero]

Efficiency can go over 100% or below 100% - it's a matter of luck. I've had some periods where it is way over 100%, also periods where it drops at 70-80%. Overall with time it should get close to 100% though. The stale counter is additive, yes.

BTW could you provide me the ISA dump?

I am mostly interested in the SQ_PGM_RESOURCES:NUM_GPRS field which should be among the last lines.

hmm...  how do i do that?

i tried running "export GPU_DUMP_DEVICE_KERNEL=3" (also 1 and 0) in tmp - but no isa file magically appeared.  i also tried while hashkill was running.

what am i doing wrong?

[gat3way]

Well hm...look for *.isa. /tmp should be writable, that's very strange.

[Jaime Frontero]

Well hm...look for *.isa. /tmp should be writable, that's very strange.

maybe try it in one of the /hashkill subdirectories?

BTW, i tried running it as sudo - it said no such program as 'export'.

[mskwik]

Still seems to have a somewhat high rate of stale shares (as reported in the deepbit stats), but only about 1.5% compared with the 10% last time I tried it.  Does report the new long polling blocks properly now.

As far as the whole untrusted code thing goes I have just been running it in a sandbox (the same as when testing other miners, open source doesn't necessarily matter if I don't have the time to look through it properly), no access to home directory, read access to standard system libs, write access to /dev/ati and /tmp and I can remap accesses to /usr/share/hashkill to something under the working directory.  Still have to trust code somewhat but it would stop any basic wallet-stealing (as well as reporting that it was tried).