Browsing the ATI’s OpenCL forums I found this post, which can be interesting:
I have a security problem… Call me paranoid but:
Would be possible to add a private/public key encrypt mechanism inside the the OpenCL driver? A reverse engineer could easily watch my precious OpenCL IP algorithms just creating a fake opencl.dll.
If you could use a private/public system would be much more secure. For example:
Each card has an hexadecimal identifier. You could use that as public key.
On the other hand, you could write a simple tool to encrypt the OpenCL source code using a private key ( for example: “ATI rocks” ) and a closed-unknown algorithm or keys (like the DCC, DVD or Bluray).
The OpenCL driver would use those keys to decrypt internally the kernel’s code. It’s very hard to debug a kernel driver, plus the difficulty to crack a private/public asymetric 1024-bits algorithm would make the system more secure.
In that way our IP will be sightly better protected! ( although no system is 100% secure, of course ).
The only silver bullet is NOT to distribute, and have some sort of cloud compute server. Not realistic for many applications for many reasons, but it will work for some. I am trying to do this, however IP protection is not the only reason. OpenCL is just too new. The cost of trying support customer’s GPUs would not scale nearly as well as compute servers. Requiring customer to install after market video drivers seems more and more like a nightmare every time I think about it.
I am also obfuscating Kernels, so I can go either way some day, but hopefully not soon.
This proposal would require changes in the spec, and I am not sure how encrypted source could be understood on multiple vendors without some sort of cooperation. Tootsie pop defenses, a single hard defense with a soft chewy prize in the center, are vulnerable if it ever became public. There is no way to recall them if compromised. I cannot imagine OpenCL vendors thrilled to do this.
And, of course, there is NOTHING you can do against a pro hacker… but the point is that non-pro-hackers won’t be able to create a fake DLL and sniff all your code. If the competency wants to steal IP they should spend millions of dollars to hire a professional reverse engineer/hacker. To break a 1024bits asymetric rotating keys + debug a OS kernel driver, again, is not for everybody.
santyhyammer, I’m sorry, but what you propose will not make getting your IP source harder. The only solution I see (and which I’ve used with CUDA and going to use with OpenCL) is to precompile your kernels into binary (or intermediate) code on developer’s side, not on customer’s computer. This of course gives adversary an access to your compiled kernel and he can reverse engineer it, but even with decuda it was not that simple.
Trying to hide private keys in modules residing on non-trusted computers is really a bad idea, just a waste of time. This particular problem cannot be solved this way.
Question, does a CUDA kernel precompiled on Windows, run on OSX & vice versa? The reason I ask is I am pretty sure this will not work with OpenCL. Next, add in that ATI was not a concern in CUDA. Also, I have read that ATI generates different precompiled code, based on the card, which is legal. Nvidia has different drivers for mobile devices. I wonder if different code might get precompiled?
Precompiled distribution looks like an order of magnitiude more difficult with OpenCL than CUDA. You also need many different devices to compile all your distributions. This could be made workable, depending on how wide you distribute, or are able to state the vendor implementations you support.
To be short: yes, it is likely that you will need access to all supported device types (NVIDIA GT200, ATI HD 5xxx and so on) to build precompiled binaries. If you claim support for particular card or platform you have to test your product on it anyway, so I do not see this as a very big problem. And I do not see another reasonable way to protect OpenCL source code.
This might be a stupid and off topic question. But why do you want to protect your IP from the non-pro hacker? The pro hacker will attack your system nonetheless, but the non-pro hacker shouldn’t cause you any economic damage.
It is interesting, on ATI forum another Russian programmer told absolutely the same as Andrei. But he also does passwords. However, it looks mad to precompile dozen of binary images. And you lost compatibility to new cards. Your customer upgrades to new card and founds that your program is not working instead of getting speedup. Heh, good way to promote buying new version of soft. Also, ATI tends to change binary instruction format from time to time in new driver releases and people from ATI forum already faced this issue with binary images. Would they stop it? I think opencl is for open source, tha name open says it all.
This is a legit concern though. For example, if you need to compute something which is covered by trade secret on a GPU, you don’t want the source code to be easily readable. Obfuscate the source code with some sort of algorithm is possible, but the readability of a obfuscated source code is generally still much better than a compiled binary. It may be possible to “assemblize” the source code (i.e. compile the source code into some assembly form and rewritten it in a C code), but that increases the risk of changing the behavior of the program.
This is not really an issue with OpenCL but with portable code in general. You can either compile to machine code or distribute some sort of interpretable code (ex. Java’s and, .NET’s bytecodes are usually trivially decompilable to high level sources). Compare with general purpose closed-source multi-platform apps, like NVIDIA drivers ;) You have a variety of pre-compiled binaries for all the different versions of Windows and distributions of Linux, times two for 32/64 bit.