问题
There are many approaches when it goes about running untrusted code on typical CPU : sandboxes, fake-roots, virtualization...
What about untrusted code for GPGPU (OpenCL,cuda or already compiled one) ?
Assuming that memory on graphics card is cleared before running such third-party untrusted code,
- are there any security risks?
- What kind of risks?
- Any way to prevent them ?
- Is sandboxing possible / available on gpgpu ?
- maybe binary instrumentation?
- other techniques?
P.S. I am more interested in gpu binary code level security rather than hight-level gpgpu programming language security (But those solutions are welcome as well). What I mean is that references to gpu opcodes (a.k.a machine code) are welcome.
回答1:
The risks are the same as with any C program. Plus you can make your whole Desktop freeze. I managed to do that once, by executing a very long calculation. The effect was that the screen did not update anymore so for instance the time on the clock widget did not change for that period. So you should use two graphics cards - one for the GPU stuff.
回答2:
GPU code can definitely be risky. Current GPUs do not provide memory protection, so essentially, every GPU kernel can access all video memory. I'm not sure if it is possible to access the host's memory as well (via memory mapping maybe?). It's not possible to preempt kernels, they can "hog" the GPU and this causes freezes if it is used for graphics output, too. (Usually the driver will terminate kernels that don't exit after a few seconds)
Supposedly, AMD's new GPU series do have some memory protection features, but I doubt they are used at the moment. It's possible to split up the GPU multiprocessors into multiple segments with current gen hardware (GeForce 4xx+, Radeon 6xxx+), but that's not really the same as real time-sliced, preempted multitasking. ;)
来源：https://stackoverflow.com/questions/4635749/untrusted-gpgpu-code-opencl-etc-is-it-safe-what-risks