-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Overwriting TMP environment variable breaks AMD ROCm in Linux #2379
Comments
That's not the case for me. You are right that TMP is set by hashcat as a workaround for buggy OpenCL runtimes, but this has no effect on ROCM. I've just tested this locally with a normal (not superuser) user.
Output:
As you can see, hashcat is not trying to write to any file in that folder and there's not a single permission denied. Just to make sure my user is not allowed to write to that folder:
|
What version of ROCm are you running, and do you have TMPDIR set in your environment? Grepping through the ROCm fork of LLVM suggests that the preferred order of environment variables to identify temporary directories is The whole point of temporary directories is to provide "scratch" space, so redirecting to a non-writeable directory seems like bad practice in general. If this is absolutely necessary, maybe the solution is to set |
While I like your PR and the way you solved it, I was thinking maybe we can get rid of this workaround in general. It goes back to a runtime which had this bug years ago and my hopes are that it is fixed for now. I have pushed commit dc9f4e9 with the idea to let it there for a while and give hashcat users some time to test and and see if there's any negative response to it. There's simply to many different opencl runtimes in different version on different platforms for me to test all of them. If it turns out to break something I will revert my test commit and use your PR. It would be nice if you can also do some testing as it seems your installation is somewhat different than all of my test systems. |
I'd be happy to just drop the TMP hack. My ROCm runtime was built for Void Linux according to PR #21153 and uses the AMD comgr library to compile for GPU targets. I'm not positive, but it looks like the official AMD packages for Ubuntu and others still used clang-ocl as of version 3.3.0, even though it depends on the depreacted hcc. Another possibility is that AMD uses some patches when building packages that didn't make it into the open-source repos. AMD has recently released ROCm 3.5.0, but I haven't been terribly motivated to try packaging the new version. I don't know whether that release is subject to the same issue. |
Handled in #2387 |
In
src/folder.c
, a comment notes that a good workaround for problematic handling of-I
parameters is to set theTMP
environment variable before loading the runtime. This is not the case for the AMD ROCm runtime in Linux, at least with the latest version (3.3.0), unless hashcat is run as the superuser.The ROCm Code Object Manager and ROCm OpenCL Runtime use the value of the
TMP
environment variable to determine where compiled objects should be placed. Lines 465 and 467 ofsrc/folder.c
set this value to${PREFIX}/share/hashcat/OpenCL
, which is not typically writeable by ordinary users. Thus, OpenCL kernel compilation fails when the build products can not be stored.While I'm not sure about other OpenCL runtimes (it certainly doesn't seem to hurt ocl-icd with the amdgpu-pro OpenCL ICD), the proper behavior for ROCm is either to leave
TMP
alone or explicitly set it to somewhere like/tmp
that can be written by any user running hashcat.The text was updated successfully, but these errors were encountered: