hashkill 0.3.1 and git do not build for ati on grsec/pax kernel #13
Comments
|
here is a better formatted output from ZeroChaos : |
|
Hm that's strange, the AMD compiler should be bailing out instantly if no AMD driver is installed. Can you check if you have previously installed fglrx on that host? |
|
it was at some point installed with the package manager, and it's no longer installed so all the files should be gone. |
|
That check is in place and it does skip on my system: Compiling amd_ipb2_long without flags... Compiling amd_ipb2 without flags... and so on Let's see what's so special about ZC setup. |
|
It might have forgotten to remove some files (even the Catalyst uninstaller itself tends to forget about some files left on the disk). I would rather check libOpenCL.so files/symlinks in /usr/lib as well as the ICD stuff that is in /etc/OpenCL/vendors. |
|
Hm, I think the output from clinfo will be also useful to debug the problem (it should come with nvidia's drivers I think). If it crashes or detects an AMD platform, this would be a strong indication that catalyst was not uninstalled properly. |
|
zero@ozzie ~ % clinfo |
|
ozzie vendors # pwd ozzie vendors # ls -al /usr/lib64/libOpenCL.so* |
|
We've done some debugging. The problem seems somewhere in the initialize_opencl function: It prints "Debug: dlopen", does not print the second "Debug: GetProcAddress" and exit quietly without printing the final message from the parent [amd-compiler.c] printf("No OpenCL library found!\n"); Would you have any ideas?.. |
|
That's very strange. Can you run ltrace (not strace) on that command? I also now noticed that the crash is in the dynamic loader library. Can you try changing RTLD_LAZY with RTLD_NOW and see if it changes? Still cannot explain why it behaves so though. |
|
While we are waiting for ZC, the only logical explanation I have is the hardened kernel settings. It might block the code execution of dlopen function, that's why we don't see the proper exit. A quick search gave this: I no expert here. |
|
ozzie compiler # ltrace ./amd-compiler amd_ipb2_long n Debug: The main AMD function dmesg |
|
The strace version of this is far more interesting to me:
mprotect appears to be blocking something here and then it dies... Running paxctl -m amd-compiler (turning off mprotect) it seems that I now get this output: I'm guessing that a bit closer to intended. Perhaps we can fix whatever is pissing off mprotect? |
|
From the PaX documentation.... The goal of MPROTECT is to help prevent the introduction of new executable The restrictions prevent
Ugh...that is not good. The executable mapping is being done by the dynamic loader library and happens when I load the plugins (or the opencl library). This is the way it works and it is outside hashkill's control. I am not very much acquainted with PaX though...are there some kind of rules which specify who can do that and who cannot? Since this is something very basic (e.g apache modules should be loaded more or less the same way). Perhaps the right way to deal with that would be to create some PaX configuration allowing hashkill to dynamically load libraries like this (dlopen/dlsym)? |
|
As far as I'm aware there is no pax configit is only possible to disable pax for the binary. Could you have a look how they do it at cryptohaze (http://sourceforge.net/projects/cryptohaze/files/) ? There is no such problem with that software. |
|
Yes - they do not load libOpenCL.so dynamically, it is rather a link-time dependency. Those are just 2 different approaches with pros and cons. E.g hashkill does not require AMD APP SDK to build and does not require two different binaries (cpu-only and cpu/opencl). However there are indeed cases like this (with pax) where this breaks. |
|
What I meant is that with cryptohaze's approach (which hashkill previously followed btw), the binary is either dynamically linked to libOpenCL, or not (depends on build-time specifics). A binary that is linked to libOpenCL would not run on a system without a GPU at all. This in turn would create headache to distributions that want to ship it in binary form. hashcat solve it in another way - they have a cpu-only cracker (hashcat) and GPU-only ones (oclhashcat-lite and oclhashcat-plus) that are completely different programs. |
|
I am going to close this (now specifying --disable-amd-ocl at configure-time should solve the issue) - still the root cause is unknown though |
|
Just to make it clear, the workaround is to run following commands during compilation: the hardened kernel does not allow to use some technique used in both compilers and disabling kernel protection (which is not cool) is the only way for now. It has nothing to do with "--disable*-ocl" options. Also, the tool itself will probably fail to run as well, so it the folowing is necessary: The title should be: ".. does not work on hardened kernel" and it is not fixed. |
|
I'm not really sure how allowing me to disable ati support allows me to successfully build with ati support... This shouldn't be closed. |
|
Ooops, sorry, should have re-read that thread before closing, looks like 10 days are enough to forget what it was really about :( Reopening it. I am now writing a mail to the PaX team to ask if there is something that can be done (programatically) to avoid that. Will keep you updated with the reply. |
|
OK, that's the response from PaX developers: ...i think the problem you ran into is this: http://forums.grsecurity.net/viewtopic.php?f=3&t=2194 if the 'bad' library in question doesn't do runtime codegen and just has an I will now check the thread as well. |
|
ZeroChaos, do you experience the same problem with any other OpenCL software? Also, does execstack -c /usr/lib/libOpenCL.so fix the issue for you? If that's the case then we should perhaps address this to the OpenCL vendor... |
|
issues like this don't appear on current git code, so let's just close this and assume everything is happy happy :-) |
|
oops, I'm stupid, this is the same bug I just reported again. sorry for the noise. |
|
execstack -c was replaced by fix-gnustack -f, however it looks like /usr/lib/libOpenCL.so wasn't set execstack in the first place so this did exactly nothing. |
gen 2 i5 with intel and nvidia graphics on gentoo hardened
nvidia-drivers-304.64
The text was updated successfully, but these errors were encountered: