Archives Discussions

[bubu]

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 ).

thx

[nou]

you can easily catch GLSL or HLSL shader code. with OpenCL it is the same. and at some point it must be decrypted to compile. javascript code on the web is the same.

so your only option is obfuscate your code.

[empty_knapsack]

Actually best option to support precompiled GPU kernels. Debugging x86 kernel driver isn't a big problem and in fact it isn't needed at all, as OpenCL/CAL not working at driver level. While disassembling ISA and figuring out how it works is a challenge.

Also, as "side effect" precompiled GPU kernels can be optimized well as it'll be programmer choice is he want to invest several hours to compilation and then have fast GPU kernels or have fast compilation and terrible performance kernels (== the current ATI model).

For VLIW architecture compiler (and its options)  much more important than for usual scalar processors (read -- nVidia). It's really amazing that currently the only thing we can do is calclCompile(no options can be passed to compiler). (And if you're think that you have some options at OpenCL level -- nah, it's only CAL/IL level that matters).

[nou]

yeah precompiled kernels will be great. and there is support in OpenCL for this.

but when you want ship only binaries of kernel  you must ship separate binaries for every card or at least for every vendor. nVidia use PTX code and ATI IL/ISA or x86 binary dll. so even now we have at least three binary formats.

so precompiled binaries do not solve security issue.

[empty_knapsack]

I'm OK with shipping several different binaries. Especially when they are works 2-4 times faster than kernels generated with run-time compilation. Also, currently there so many targets (710, 730, 770, 870 & 830(or is it 840?)) while resulting binary code is exactly the same except for device id. It simply pointless to compile one piece of code 5 times (especially when it takes 10-20 minutes) to receive (almost) same binaries. It'll great to have some "precompiled-IL->ISA" format which is almost ready to use binary code, something like .obj.

Also having several functions entries at IL instead of single main is must in fact.

However I doubt ATI will ever make it possible, they should make IL->ISA compiler open source not the pointless Brook+ .

[bubu]

Precompiled binaries -> A compiled CL kernel for a R700 won't work in a R800. Neither on NVIDIA or S3. I don't like to code 18 times the same or to create 18 different executables

Obfuscation -> It's not really a solution, because a hacker could just create a fake OpenCL.dll and sniff my de-obfuscated code in the clCompileKernel call.

On the contrary, performing the asymetric decryption in the OS kernel driver it's fine... because just a few persons in the world know how to debug the OS kernel properly... plus a 1024 bits asymetric public/private key could take a lot of effort to be cracked. Even if it's some day cracked, just change your keys in the next driver release and the crack won't work.

[nou]

empty_knapsack: i think binaries in OpenCL is meant to "cache" program. so if user run your program first time you will normaly compile kernel and save binaries on the disk. so second time it will load this cached binaries.

bubu: you can still make your code harder to read with something like this.

int hfbss = sgx[hsfg]+hsdf[abxxbf];
hfbss *= aatpks;

this random variable names and without comments you can achive "some" security.

on the other hand to ensure BlueRay have spend millions of dolars and what is result.

[empty_knapsack]

@bubu

The scheme you're talking about will be cracked in no time. Again, OpenCL/CAL isn't working at kernel level, the executable ISA/IL is ready long before kernel mode and so it's easily possible to intercept it. As well as it's easy to recover public key from disassembly of kernel driver and it need to be done only once to get access to all kernels "protected" this way. Also ATI cannot afford to use some executable code protection at kernel level because (to be honest) it's already enough problems with stability to increase them by adding some working-as-any-other-in-weird-way protection.

As for precompiled binaries -- you don't need to code 18 different kernels. You need to add 18 lines to your makefile and everything will be done automatically. If precompiled binaries will ever be supported (though they're exists in OpenCL specification).

 And nou's example with BlueRay is nicely describe everything. Point is -- if your code will be unprotected at some moment (or protected only by software tricks) -- it'll intercepted and stolen. You need to add these asymmetric encryption to hardware to make it works. But in this case private key must be really private, so every kernel will be signed/encrypted only by ATI == more work to be done when there are already enough problems with OpenCL == I doubt anyone will care enough to implement it.

Shortly, precompiled kernels is the easiest and best option right now. Sadly it doesn't works with OpenCL.