Los ingenieros de Google que contribuyen al Kernel de Linux han anunciado que han descubierto cientos de “Race Conditions”, en el kernel usando KCSAN. La compañía ha estado trabajando durante mucho tiempo en AddressSanitizer para encontrar errores relacionados con la corrupción de la memoria o en UndefinedBehaviorSanitizer para un comportamiento indefinido en el código.
Esta vez, Google ofrece un nuevo detector “Race Conditions” para el kernel de Linux que se llama KCSAN (Kernel Concurrency Sanitizer). Estas vulnerabilidades críticas no son nuevas. De hecho las “Race Conditions” ocurren cuando dos o más subprocesos en el mismo proceso acceden simultáneamente a la misma ubicación de memoria, donde al menos uno de los accesos es para escribir, y cuando los subprocesos no usan ningún bloqueo exclusivo para controlar su acceso a esta memoria.
(adsbygoogle = window.adsbygoogle || []).push({});
Cuando se cumplen estas condiciones, el orden de acceso no es determinista y el cálculo puede dar resultados diferentes de una ejecución a otra dependiendo de este orden.
Las Race Conditions se ven cada vez más como errores de acceso simultáneo y son difíciles de duplicar y diagnosticar en programas paralelos. El kernel de Linux es un sistema de software a gran escala, en el que el paralelismo intensivo de subprocesos y el intercalado de subprocesos no determinista están más sujetos a condiciones competitivas.
Algunas situaciones competitivas pueden ser benignas, pero gran parte de ellas identificadas hasta ahora se consideran errores.
(adsbygoogle = window.adsbygoogle || []).push({});
El kernel de Linux proporciona varios mecanismos para evitar y gestionar este tipo de condiciones ya que existen herramientas como Thread Analyzer o KTSAN (Kernel Thread Sanitizer) para detectar errores críticos de ejecución en el Kernel de Linux.
Sin embargo, Google, que también contribuye al Kernel de Linux, propuso recientemente KCSAN, un nuevo detector de Race Conditions para el Kernel, similar a KTSAN.
Según Google, KCSAN se enfoca en descubrir situaciones competitivas en el código del Kernel. Este detector dinámico de golpes críticos es una alternativa al Kernel Thread Sanitizer (KTSAN).
Según la explicación de Google, KCSAN se basa en puntos de monitoreo de muestreo, a diferencia del detector KTSAN, que es un detector de carrera crítico antes del evento. Las prioridades clave en el diseño de KCSAN son la falta de falsos positivos, escalabilidad y simplicidad.
KCSAN utiliza herramientas de compilación para acceder a la memoria. KCSAN es compatible con los compiladores GCC y Clang. Con GCC, requiere la versión 7.3.0 o posterior y con Clang, requiere la versión 7.0.0 o posterior.
En la página GitHub del proyecto, Marco Elver de Google escribió que al usar KCSAN en pruebas el mes pasado, encontraron en solo dos días más de 300 situaciones de competencia únicas en el núcleo. KCSAN proporciona varias opciones de configuración para personalizar su comportamiento.
“Hemos estado usando KCSAN a través de Syzkaller durante varias semanas, y hemos encontrado muchos errores. Inicialmente en septiembre de 2019, identificamos más de 300 situaciones de competencia únicas durante solo dos días “, escribió.
Google dijo que el enfoque general se basa en DataCollider, otro detector dinámico de situaciones competitivas en los módulos del núcleo. Pero a diferencia de DataCollider, KCSAN no utiliza puntos de monitoreo de hardware, sino que se basa en herramientas de compilación.
Los puntos de monitoreo se implementan utilizando una codificación eficiente que almacena el tipo, el tamaño y la dirección de acceso en un archivo largo. Los beneficios de usar puntos de monitoreo flexibles son la portabilidad y una mayor flexibilidad para limitar el acceso que puede activar un punto de monitoreo.
Estos son algunos de los puntos clave que KCSAN hizo por Google:
- Alto rendimiento: el tiempo de ejecución de KCSAN es mínimo y no requiere bloqueo de estado compartido para cada acceso. El resultado es un rendimiento mucho mejor que KTSAN.
- Sin memoria adicional: según Google, no se requiere caché. La implementación actual utiliza una pequeña cantidad de largos para codificar la información del punto de monitoreo, lo cual es insignificante
- Comando de memoria: KCSAN no conoce las reglas de control del modelo de memoria del kernel de Linux (LKMM). Esto puede resultar en carreras críticas perdidas (falsos negativos) en comparación con un detector de carrera antes del evento como KTSAN
- Precisión: según Google, KCSAN es impreciso porque utiliza una estrategia de muestreo;
- Requiere anotación: se requiere una anotación mínima fuera del tiempo de ejecución de KCSAN. En el caso de un detector de eventos previo a la condición, cualquier omisión conduce a falsos positivos, lo cual es particularmente importante en el contexto del núcleo que incluye mecanismos de sincronización personalizados.
- Detección de escrituras dinámicas desde dispositivos: al verificar los valores de datos durante la configuración del punto de observación, también se pueden detectar escrituras dinámicas desde dispositivos.
from Linux Adictos https://ift.tt/33kz8A1
via IFTTT
Pacosite's Blog 