Hey experts!
It seems like a security flaw being able to dump the SASS or PTX from a binary via cuobjdump. Is there a nvcc compilation flag or a method such that all SASS & PTX is not vulnerable to exposure via cuobjdump?
Thanks :)
Does it also seem like a security flaw to you that one can use the system utility objdump to dump the x86 assembly code of any executable on your PC, workstation, or server? Have you ever used a powerful disassembly tool such as IDApro?
IMHO, there is little point in keeping machine code secret, security through obscurity doesn’t work.
Hmmm fair point. No I have not but I will check it out now.
Thanks for the help!
If the “try it out” comment applies to trying IDApro: This is a pretty pricey professional tool, not open source software. I don’t know of a sophisticated open-source disassembler, objdump just provides the most basic functionality.
How would it be a security flaw in the first place?
While I have done a little bit of work in that space, I am not a security expert by any stretch of the imagination.
My understanding is that being able to peruse code is only an issue with unsuitable approaches to security. For example, some app could utilize encrypted data, but have the key(s) hard-coded in the application. Disassembling the code then allows an attacker to recover the key(s) and decrypt the data.
Lol! I couldn’t even imagine doing something like that!
Well, thanks for elaborating though.
I wonder whether the original poster was really talking about copy protection. In that case obfuscation is about the best you can hope for.
Its true that x86 machine code can also be disassembled but it can sometimes be like looking for a needle in a haystack. The fact that CUDA kernels tend to be a relatively small number of instructions that have received a lot of careful optimization does tend to make them quite high value targets.
There are toolkits to make disassembly of x86 machine code more difficult and one of the approaches they use is to encrypt the executable. This would presumably provide some level of protection for any CUDA kernels although at some point they will have to exist in decrypted form (as will the x86 machine code) and my guess is that they would still be very vulnerable at the point where they are passed to the CUDA device/runtime libraries.
As someone who has spent (too) many hours of my life deciphering both x86 assembly and SASS (mostly to track down compiler bugs, some of which the compiler folks claimed could not possibly be there :-) I can assure you that SASS is even more difficult to back-annotate into something fit for human consumption than x86, even for fairly small kernels.
And with powerful disassemblers available in the x86 world, finding the right portion of the hay stack to look at is often not that difficult, making the effort for examining CPU and GPU code roughly comparable. The “secret sauce” of many x86-based programs often boils down to a few short key routines (clever SIMD kernels, for example), so the situation is not much different from examining CUDA kernels.
Any determined adversary will be able to extract and understand machine code, so trying to hide anything there is a fruitless exercise, IMHO.
Apropos paper about reverse engineering and obfuscicating CUDA code. An interesting paper more about strategies to disassemble and analyze a given binary, but at the end there is a short section on protection recommendations. The two big suggestions are to rename function and variable names to remove any clues, and to generate final binaries only with SASS for the specific architectures you want to support, and not PTX. The downside is you cannot JIT those kernels onto new architectures, or benefit from bug or performance improvements with compiler/driver updates.