I recently graduated from college and have been working for a medical imaging SDK company for about a year. I am beginning to learn GPGPU and am very interested in leveraging the parallel processing capabilities of GPU’s; but, I have the following question.
How safe can my code be from potential theft? It is my understanding that a kernel is transferred through the host’s memory to the video card’s memory for execution via what is essentially a string. What is to prevent someone from reading this string from memory and stealing the code? This is critically important to me because GPGPU is literally useless to my company if it risks exposing our intellectual property to theft. I’m curious if this is something that has been considered and how it has been addressed. I haven’t seen much discussion on this.
The GPU code in CUDA is (depending on how you compile it) either binary object code just as for the CPU, or assembler code for a virtual GPU architecture. The latter has the advantage that it also runs on future Nvidia GPU generations.
The runtime compilation of a string with source code approach is used in OpenCL.
Awesome. Thanks for elaborating on that. Like the idea of OpenCL and making things cross-platform compatible; but, sounds like CUDA may be a more viable option given the code protection aspect.
CUDA also has a more comprehensive set of features !
But how is it that by storing it in an elf-format file and you’ll be able to avoid theft? When hackers have access to your machine, and thus your binaries, there’s hardly anything they can’t take away. Of course source code would not be directly available, but assembly code, for many, is more than enough.
You should take a look at the PTX output of a kernel (–ptx flag to nvcc) and see if this meets your obfuscation requirements. (Possibly after stripping the comments inserted by the compiler.) Given that there are several cubin decompilers (including one shipped by NVIDIA), I don’t think that there is much advantage to cubin over PTX. Both are low-level assembly-level languages with no information about variable names used in CUDA C code. Plus, PTX has the advantage mentioned earlier of being translatable by the driver to newer CUDA architectures.
Having never worked in a field where obfuscation is a goal: What is your threat model? How much skill and resources do you assume your typical adversary has? I’m just curious what criteria you use to evaluate the risk of theft.
The threat isn’t likely to be incredibly heavy on skill and resources as we don’t have reason to expect pro hackers. The more likely scenario would be someone who works for a competitor and hacks in his or her spare time fiddling with our SDK DLLs. So, we want to make sure there is a high enough level of deterrence to prevent such individuals from getting far with their reverse engineering.
OK, personally, I would find the compiled PTX a mostly adequate deterrent to casual reverse engineering, though your kernel function names and parameter names will show up. Perhaps a quick obfuscation script applied at the PTX level would be sufficient.
hmm… just to add on a bit, I think obfuscation for CUDA code should be possible. I can’t think of a likely mechanism that should prevent instructions stored in global mem from being modified(even if the instructions at specific locations are cached, polluting the entire cache and making it reload should be easy). It seems CUDA does not exercise a strict control on memory access.
Store enciphered opcode in cubin. Load it, decipher in on GPU, and call it.
But of course, only hardware methods can stop pro crackers.