Recuerde todos esos errores con nombres funky de la memoria reciente, como Espectro, Fusión de un reactor, F ** CKWIT y rambleed?

En pocas palabras, este tipo de errores (quizás se describan mejor como "costos de rendimiento") son un efecto secundario de la demanda cada vez mayor de CPU cada vez más rápidas, especialmente ahora que la computadora o el teléfono móvil promedio tienen múltiples chips de procesador. , normalmente con varios núcleos o subunidades de procesamiento, integrados en cada chip.

En los viejos tiempos (me refiero a la era de los chips como el Inmos Transputer), la sabiduría recibida decía que la mejor manera de hacer lo que se conoce en la jerga como "computación paralela", donde se divide un gran trabajo en muchos más pequeños y trabajar en ellos al mismo tiempo, era tener una gran cantidad de procesadores pequeños y baratos que no compartían ningún recurso.

Cada uno tenía sus propios chips de memoria, lo que significa que no necesitaban preocuparse por la sincronización del hardware cuando intentaban sumergirse en la memoria de los demás o mirar el estado del procesador de los demás, porque no podían.

Si el trabajo 1 quería entregar un resultado intermedio al trabajo 2, se necesitaba algún tipo de canal de comunicaciones dedicado y, por lo tanto, se evitaba por completo la interferencia accidental de una CPU en el comportamiento de otra.

Los chips transputer tenían cada uno cuatro líneas de datos en serie que les permitían conectarse en una cadena, malla o red, y los trabajos tenían que codificarse para adaptarse a la topología de interconexión disponible.

Compartir nada versus compartir todo

Este modelo fue llamado compartir nada, y se basaba en la idea de que permitir que varias CPU compartieran los mismos chips de memoria, especialmente si cada CPU tenía su propio almacenamiento local para copias en caché de datos usados ​​recientemente, era un problema tan complejo por derecho propio que dominaría el costo, y aplastar el rendimiento, de Compartir todo computación paralela.

Pero las computadoras que comparten todo resultaron ser mucho más fáciles de programar que los sistemas que no comparten nada, y aunque por lo general le daban una menor cantidad de procesadores, su poder de cómputo era igual de bueno, o mejor, en general.

Así que compartir todo fue la dirección en la que finalmente se dirigió la relación precio/rendimiento y, por lo tanto, el mercado.

Después de todo, si realmente quisiera, siempre podría unir varias computadoras paralelas compartidas utilizando técnicas de compartir nada (intercambiando datos a través de una LAN económica, por ejemplo) y obtener lo mejor de ambos mundos.

Los costos ocultos de compartir

Sin embargo, como nos recuerdan Spectre, Meltdown y sus amigos, el hardware del sistema permite que programas separados en núcleos de procesador separados compartan la misma CPU física y chips de memoria, pero sin pisar los dedos de los demás...

…puede dejar restos fantasmales o indicadores de cómo se comportaron recientemente otros programas.

Estos remanentes espectrales a veces se pueden usar para descubrir qué estaban haciendo realmente otros programas, tal vez incluso revelando algunos de los valores de datos con los que estaban trabajando, incluida información secreta como contraseñas o claves de descifrado.

Y ese es el tipo de falla detrás CVE-2022-0330, error del kernel de Linux en el controlador de la tarjeta gráfica Intel i915 que fue parcheado la semana pasada.

Las tarjetas gráficas Intel son extremadamente comunes, ya sea solas o junto con tarjetas gráficas "estilo jugador" más especializadas y de mayor rendimiento, y muchas computadoras comerciales que ejecutan Linux tendrán cargado el controlador i915.

No podemos, y realmente no queremos, pensar en un nombre extraño para la vulnerabilidad CVE-2022-0330, así que nos referiremos a ella como el drm/i915 error, porque esa es la cadena de búsqueda recomendada para encontrar el parche en los últimos registros de cambios del kernel de Linux.

Para ser honesto, este probablemente no sea un error que cause una gran preocupación a muchas personas, dado que un atacante que quisiera explotarlo ya necesitaría:

• Acceso local al sistema. Por supuesto, en un entorno informático científico, o un departamento de TI, eso podría incluir una gran cantidad de personas.
• Permiso para cargar y ejecutar código en la GPU. Una vez más, en algunos entornos, los usuarios pueden tener "poderes de codificación" de la unidad de procesamiento de gráficos (GPU) no porque sean jugadores ávidos, sino para aprovechar el enorme rendimiento de la GPU para la programación especializada, desde la representación de imágenes y videos, hasta cryptomining, a la investigación criptográfica.

En pocas palabras, el error involucra un componente del procesador conocido como TLB, abreviatura de Búfer de búsqueda de traducción.

Los TLB se han integrado en los procesadores durante décadas y están ahí para mejorar el rendimiento.

Una vez que el procesador ha determinado qué chip de memoria física está actualmente asignado para contener el contenido de los datos que el programa de un usuario enumera como, digamos, "dirección #42", el TLB permite que el procesador eluda los muchos cálculos repetidos de direcciones de memoria que podrían de lo contrario, se necesitaría mientras un programa se ejecutaba en un bucle, por ejemplo.

La razón por la que los programas normales se refieren a las llamadas direcciones virtuales, como "42", y no se les permite introducir datos directamente en celdas de almacenamiento específicas en chips específicos es para evitar desastres de seguridad. Cualquiera que codificara en los días de gloria de los ordenadores domésticos de la década de 1970 con versiones de BASIC que le permitieran eludir cualquier control de memoria en el sistema sabrá cuán catastrófico es un nombre acertado pero suministrado de manera inepta. POKE el comando podría ser.)

La drm/i915 error

Aparentemente, si hemos entendido la drm/i915 bug correctamente, se le puede “hacer cosquillas” de la siguiente manera:

• El usuario X dice: "Haga este cálculo en la GPU y use el búfer de memoria compartida Y para los cálculos".
• El procesador crea una lista de entradas TLB para ayudar al controlador de la GPU y al usuario a acceder al búfer Y rápidamente.
• Kernel finaliza los cálculos de la GPU y devuelve el búfer Y al sistema para que otra persona lo use.
• Kernel no vacía los datos TLB que le dan al usuario X una "vía rápida" a algunas o todas las partes del búfer Y.
• El usuario X dice: "Ejecute más código en la GPU", esta vez sin especificar un búfer propio.

En este punto, incluso si el núcleo mapea el segundo lote de código de GPU del usuario X en un fragmento de memoria completamente nuevo, seleccionado por el sistema, el código de GPU del usuario X seguirá accediendo a la memoria a través de las antiguas entradas de TLB.

Por lo tanto, algunos de los accesos a la memoria del Usuario X leerán inadvertidamente (o deliberadamente, si X es malévolo) datos de una dirección física obsoleta que ya no pertenece al Usuario X.

Esos datos podrían contener datos confidenciales almacenados allí por el Usuario Z, el nuevo "propietario" del búfer Y.

Por lo tanto, el Usuario X podría echar un vistazo a fragmentos de los datos de otra persona en tiempo real, y tal vez incluso escribir algunos de esos datos a espaldas de la otra persona.

Explotación considerada complicada

Claramente, explotar este error con fines de ciberataque sería enormemente complejo.

Sin embargo, es un recordatorio oportuno de que cada vez que se ponen en juego los atajos de seguridad, como tener un TLB para eludir la necesidad de volver a evaluar los accesos a la memoria y, por lo tanto, acelerar las cosas, la seguridad puede verse peligrosamente erosionada.

La solución es simple: invalidar siempre, o enjuagar, el TLB cada vez que un usuario termina de ejecutar un fragmento de código en la GPU. (El código anterior esperó hasta que alguien más quiso ejecutar un nuevo código de GPU, pero no siempre se registró a tiempo para suprimir la posible omisión del control de acceso).

Esto asegura que la GPU no se pueda usar como una "sonda de espionaje" para PEEK ilícitamente en datos que algún otro programa ha confiado POKEd en lo que supone que es su propia área de memoria exclusiva.

Irónicamente, parece que el parche se codificó originalmente en octubre de 2021, pero no se agregó al código fuente de Linux debido a la preocupación de que podría reducir el rendimiento, al tiempo que corrige lo que en ese momento parecía una "falla" en lugar de un error absoluto. .

¿Qué hacer?

• Actualice a la última versión del kernel. Las versiones compatibles con el parche son: 4.4.301, 4.9.299, 4.14.264, 4.19.227, 5.4.175, 5.10.95, 5.15.18 y 5.16.4.
• Si su Linux no tiene la última versión del kernel, verifique con el mantenedor de su distribución para ver si este parche ha sido "retrocedido" de todos modos.

Por cierto, si no necesitas y no has cargado el i915 controlador (y no está compilado en su kernel), entonces no se ve afectado por este error porque es específico de ese módulo de código.

Para ver si el controlador está compilado, intente esto: $ gunzip -c /proc/config.gz | grep CONFIG_DRM_I915= CONFIG_DRM_I915=m <--driver es un módulo (así que solo se carga bajo demanda) Para ver si el controlador modular está cargado, intente: $ lsmod | grep i915 i915 3014656 19 <--driver is uploaded (y utilizado por otros 19 drivers ttm 77824 1 i915 cec 69632 1 i915 [. . .] video 49152 2 acpi,i915 Para comprobar la versión del kernel de Linux: $ uname -srv Linux 5.15.18 .1 #29 SMP PREEMPT Sáb 12 de enero 16:47:2022 CST XNUMX

• Coinsmart. El mejor intercambio de Bitcoin y criptografía de Europa.
• Platoblockchain. Inteligencia del Metaverso Web3. Conocimiento amplificado. ACCESO LIBRE.
• CriptoHawk. Radar de altcoins. Prueba gratis.
• Fuente: https://nakedsecurity.sophos.com/2022/02/01/linux-kernel-patches-performance-can-be-harmful-bug-in-video-driver/