2011-01-08 8 views
11

Hay muchos enfoques cuando se va sobre la ejecución de código no confiable en la CPU típica: cajas de arena, falsos de base, la virtualización ...Código GPGPU no confiable (OpenCL, etc.): ¿es seguro? ¿Qué riesgos?

¿Qué hay de código no confiable para GPGPU (OpenCL, CUDA o ya compilados uno)?

Suponiendo que la memoria de la tarjeta gráfica se borra antes de ejecutar dicho código no confiable de terceros,

  • ¿Hay riesgos de seguridad?
  • ¿Qué tipo de riesgos?
  • ¿Alguna manera de prevenirlas?
    • Es sandboxing posible/disponible en gpgpu?
    • tal vez instrumentación binaria?
    • otras técnicas?

P. S. Estoy más interesado en la seguridad del nivel de código binario gpu que en la seguridad del lenguaje de programación gpgpu de alto nivel (pero esas soluciones también son bienvenidas). Lo que quiero decir es que las referencias a los códigos de operación gpu (código de máquina a.k.a) son bienvenidos.

+0

Gracias Navi por la respuesta. Suponiendo que usaría una tarjeta de gpu separada para los cálculos (por ejemplo, Tesla más antiguo ...). ¿Cómo asegurar tales ejecuciones de código que no es de confianza? –

Respuesta

2

Los riesgos son los mismos que con cualquier programa C. Además, puedes congelar todo tu escritorio. Logré hacer eso una vez, ejecutando un cálculo muy largo. El efecto fue que la pantalla no se actualizó más, por lo que, por ejemplo, el tiempo en el widget del reloj no cambió durante ese período. Entonces deberías usar dos tarjetas gráficas, una para las cosas de la GPU.

+0

Ok, entonces supongamos que tenemos una tarjeta separada para el procesamiento de la CPU. ¿Qué riesgos son entonces? Usted ha escrito "lo mismo que con cualquier programa C", en realidad ... El programa "C" puede ejecutar fácilmente "sistema()", ¿qué podría pasar en el caso anterior? –

2

El código de la GPU definitivamente puede ser riesgoso. Las GPU actuales no brindan protección de memoria, por lo que esencialmente, cada kernel GPU puede acceder a toda la memoria de video. No estoy seguro de si es posible acceder también a la memoria del host (¿a través del mapeo de memoria?). No es posible adelantarse a los núcleos, pueden "enganchar" la GPU y esto causa congelamientos si también se utiliza para la salida de gráficos. (Por lo general, el controlador terminará los núcleos que no salen después de unos segundos)

Supuestamente, la nueva serie de GPU de AMD tiene algunas características de protección de memoria, pero dudo que se utilicen en este momento. Es posible dividir los multiprocesadores de la GPU en múltiples segmentos con el hardware gen actual (GeForce 4xx +, Radeon 6xxx +), pero eso no es realmente lo mismo que la multitarea en tiempo real y cortada en tiempo real. ;)

+0

En realidad, las GPU de NVIDIA han tenido protección de memoria (con una MMU) de al menos la serie 8000. No sé sobre ATI. Por ejemplo, no debería ser posible provocar una escalada de privilegios a partir de un proceso de espacio de usuario mediante el uso de código GPU. – wump

+0

wump: ¿estás seguro? Ya que parece ser bastante claro que no hay protección de memoria. Escribir fuera de los búferes de memoria asignados puede ocasionar todo tipo de cosas extrañas, incluidos los bloqueos del sistema host (en G80/GT200, no se han probado en GF100). Ciertamente no hay una MMU activa para proteger la memoria, incluso si existe. – dietr

+0

De hecho, es posible bloquear la GPU al escribir fuera de los búferes de memoria asignados. Si esta es la misma CPU que se utiliza para renderizar, su sistema se bloqueará. Siempre he supuesto que esto se debe a errores en el controlador.Sin embargo, la MMU está allí activa y evita que un proceso escriba en el espacio de memoria de otro proceso. Creo * que si tiene una GPU separada no es posible bloquear su sistema de esta manera. – wump

Cuestiones relacionadas